Mike, et al.
Do you see any reason why there should ever be a mix of signed and unsigned in the same message? I understand this cannot happen for JWT, however it will be able to occur for the JSON version of the JOSE data structures. This would be a case where many of the current systems which have different objects returned from a library would be in deep trouble as they would need to return a JOSE_Signed for part of the object and a JOSE_Unsigned for another part. I think it would be a good idea if these concepts could not be mixed together. How are other system implementers dealing with this possibility? Do you only handle the compact serialization and thus have not thought about it? Jim From: [email protected] [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Wednesday, August 21, 2013 9:32 PM To: Manger, James H Cc: Mike Jones; jose issue tracker; [email protected]; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed 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
