I also think giving plain JOSE objects their own document, apart from the JWS spec, will make it easier for developers to understand the matter and get their implementations (libraries) as we intend, and thus save them from possible confusion.
The other day a developer filed a bug report, which eventually got tagged as won't fix, that is symptomatic of the issue: https://bitbucket.org/nimbusds/nimbus-jose-jwt/issue/58/make-none-a-valid-jws-alg-type Here I wish to clarify that what I support is an editorial change that will not affect implementations, save for specifying a new MIME type header for the plain objects. Mike, you are the editor of the whole spec suite and know the texts, their structuring and how they're linked together probably better than any one of us. Do you see an elegant workable path to have all plain JOSE related stuff moved into a document of its own? Are there any IETF-related implications to that, which could pose a problem? Today I went through the latest versions of the JOSE specs. The JWS has no mention of unprotected JWSs in the main body, only in Appendix 5 (the examples). The JWA spec mentions "none" only in section 3.1 (the alg table) and section 3.6. It so appears that the changes that will have to made will be relatively localised. Having reread the specs it now looks like the WG has produced some really useful, well defined and structured documents. The only bit that feels awkward and difficult to explain to readers is having that JWS alg "none". We have the JWS spec claim, in the opening sentence of the abstract, that it is "means of representing content secured with digital signatures or Message Authentication Codes (MACs)" and then mention later that a JWS may actually also be unprotected. Which, logically speaking, goes against all claims that the JWS spec makes in its abstract and also in various places in the terminology section. Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : [email protected] -------- Original Message -------- Subject: Re: [jose] #36: Algorithm "none" should be removed From: Richard Barnes <[email protected]> Date: Thu, August 22, 2013 5:32 am To: "Manger, James H" <[email protected]> Cc: Mike Jones <[email protected]>, jose issue tracker <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
