I don't understand your second sentence below. It can happen because of having multiple signers. For example, the first could be RS256 and the second could be none.
Jim From: Mike Jones [mailto:[email protected]] Sent: Thursday, August 22, 2013 8:19 AM To: Jim Schaad Cc: [email protected] Subject: RE: [jose] #36: Algorithm "none" should be removed I don't know of any use cases requiring that. You're right that it can't happen in the Compact Serialization. It can only happen in the JSON Serialization because of the option of having unprotected header parameters (I concept I'm still dubious of). -- Mike From: Jim Schaad [mailto:[email protected]] Sent: Thursday, August 22, 2013 8:02 AM To: Mike Jones Cc: [email protected] Subject: RE: [jose] #36: Algorithm "none" should be removed 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
