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

Reply via email to