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]>
[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]<mailto:[email protected]>;
[email protected]<mailto:[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]<mailto:[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
