> If we have to invent a new standard each time an existing standard is
implemented with a security flaw, we have a lot of work to do.

You fundamentally cannot fix a standard with unusable to the point of
broken negotiation by extending the negotiation. If you don't want PASETO
to be a new standard, call it JOSEv3.

On Fri, Apr 20, 2018 at 11:18 AM Mike Jones <Michael.Jones=
[email protected]> wrote:

> The JWT Best Current Practices (BCP) draft catalogs the different
> implementation mistakes that have been documented and describes how not
> make them.  The timing of this discussion is good because the draft is
> currently in working group last call - through Monday, April 30th.  Have a
> look at https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01.  If you
> believe that additional content is needed, please send your reviews to
> [email protected].
>
> Also, see Neil Madden's draft
> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 on
> misuse-resistant cryptography for JOSE.  I've encouraged him to take it
> forward.  Please provide feedback on that as well.
>
>                                 -- Mike
>
> -----Original Message-----
> From: Cfrg <[email protected]> On Behalf Of Carsten Bormann
> Sent: Friday, April 20, 2018 4:03 AM
> To: Neil Madden <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [Cfrg] [jose] RFC Draft: PASETO - Platform-Agnotic SEcurity
> TOkens
>
> On Apr 20, 2018, at 12:49, Neil Madden <[email protected]> wrote:
> >
> > insecure implementations of old standards don’t go away because you
> introduce a new standard
>
> Exactly.
>
> If we have to invent a new standard each time an existing standard is
> implemented with a security flaw, we have a lot of work to do.
>
> Insecure implementations exist even of standards such as TLS.  Usually the
> strategy is to fix the implementations.  (It is also a good idea to
> envision what implementers will mess up when creating a new standard.  But
> there are limits to that approach.)
>
> One of the objectives in the definition of COSE was to avoid some of the
> pitfalls of JOSE.
> There is also work ongoing to document the security considerations of JOSE
> better, e.g., draft-ietf-oauth-jwt-bcp.
>
> I’d like to focus the energy that appears to be visible here on agreeing
> good SIV constructions and getting them registered with COSE.
>
> Grüße, Carsten
>
> _______________________________________________
> Cfrg mailing list
> [email protected]
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> [email protected]
> https://www.irtf.org/mailman/listinfo/cfrg
>
-- 
David Adrian
https://dadrian.io
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to