I would be happy enough with 3 buckets: 1. Things that are integrity-protected (JWS) 2. Things that are encrypted and integrity-protected (JWE) 3. Things that are not protected (TBD; JWP in my proposed text)
On Wed, Aug 21, 2013 at 9:01 PM, Manger, James H < [email protected]> wrote: > Mike said:**** > > “the defense against downgrade attacks needs to happen in the library > interface design, as ekr suggested”**** > > ** ** > > I think there is general agreement (if “none” is allowed at all) that the > JOSE library interface is the place to make sure an app can’t accidentally > accept an "alg": "none" message when it only expected authentic messages.* > *** > > ** ** > > However, we are not writing a library interface; we are specifying a > message format.**** > > ** ** > > I doubt any advice in a JOSE spec about library interfaces will be given > much attention. Libraries are just as likely to develop an interface that > matches the structure of the JOSE specs – and that structure currently > treats "none" as a signature algorithm.**** > > ** ** > > The Nimbus JOSE+JWT library [ > https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home] appears to > handle "alg": "none" fairly well. It treats "alg": "none" as a distinct > type of JOSE message (PlainObject), distinct from a JWE (JWEObject), and > distinct from a JWS (JWSObject). Calling JWSObject.parse(<"alg": "none" > message>) fails. This is good.**** > > The spec should reflect this desirable structure. It should not pretend > “none” is a variety of signed message.**** > > ** ** > > This would be easy if we had a JOSE spec, with sections (or other specs) > for signed, MACed, directly encrypted, plain, key exchange+encryption, etc > – instead of 2 buckets (JWS, JWE) that everything has to fit in.**** > > ** ** > > --**** > > James Manger**** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
