As I think Richard has pointed out previously, we've got much better (and cheaper) detection schemes than the "alg" property:
* compact: 2 dots == JWS, 4 dots == JWE (else !JOSE) * JSON: "signatures" == JWS, "ciphertext" == JWE (else !JOSE) Counting dots in the compact serialization requires significantly less effort than decoding then parsing then analyzing the header. Checking for property existence in the JSON (de) serialization also requires (arguably significantly) less effort than merging the various headers (one with an additional base64url decode step) in the appropriate manner. It's boggling to me that so many accept a ready-made (REQUIRED!) exploit because it's incompatible with existing implementations. We've broken compatibility in the past for good reasons, and this seems like an awfully good reason to do the same. - m&m Matt Miller < [email protected] > Cisco Systems, Inc. On Aug 19, 2013, at 2:30 PM, Mike Jones <[email protected]> wrote: > Because it breaks the invariant that you use the “alg” parameter value to > determine how to process the JOSE object. > > From: Phil Hunt [mailto:[email protected]] > Sent: Monday, August 19, 2013 1:29 PM > To: Mike Jones > Cc: Richard Barnes; John Bradley; jose issue tracker; Justin Richer; > [email protected]; [email protected] > Subject: Re: [jose] #36: Algorithm "none" should be removed > > I think it is dangerous to say signature is valid if alg:none. Richard is > right. The app will get a binary response and will assume there was a > signature. > > Why not simply detect if "alg":"somealg" is present and if not, proceed > direct to payload processing? > > Phil > > @independentid > www.independentid.com > [email protected] > > > > > > > > On 2013-08-19, at 1:23 PM, Mike Jones <[email protected]> wrote: > > > It is accepted. That doesn’t mean that the application should accept it > unless it validates that the actual algorithm used meets its security > requirements, whether it’s “none”, or not. (For instance, if you require > HS512 or ES512, your application will need to reject inputs that used HS256, > etc.) This is a basic requirement for secure applications – not a new > requirement created by the presence of “none”. > > -- Mike > > From: Richard Barnes [mailto:[email protected]] > Sent: Monday, August 19, 2013 1:21 PM > To: Mike Jones > Cc: John Bradley; Justin Richer; jose issue tracker; [email protected]; > [email protected] > Subject: Re: [jose] #36: Algorithm "none" should be removed > > But that signature is valid for that algorithm. So a generic JWS parser will > show it as accepted. > > > On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones <[email protected]> > wrote: > Having an empty signature segment already makes it recognizably different. > > From: Richard Barnes [mailto:[email protected]] > Sent: Monday, August 19, 2013 1:18 PM > To: John Bradley > Cc: Justin Richer; jose issue tracker; Mike Jones; [email protected]; > [email protected] > Subject: Re: [jose] #36: Algorithm "none" should be removed > > On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[email protected]> wrote: > In OAuth and Connect there are cases where you are receiving tokens from > multiple sources. By allowing none as a alg option we can process signed or > unsigned tokens with the same basic handler by inspecting the first segment. > I note currently that while none has three segments the last segment must be > empty. I think that is sufficient to keep people from becoming confused. > > Making it two segments will break existing parsers for no good reason. > > No, there's a very good reason. Something that is not signed should not be > accepted as a JSON Web Signature object. Acceptance of a JWS implies that > the payload and protected headers were integrity protected from the signer; > that is not true for "alg":"none". > > Also, it's not clear that this change will break existing parsers. For > example, the NimbusDS parser would successfully parse a two-segment object as > a "plain JWT" > <https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master> > > > What we call it I am flexible about, if it is a unsigned JOSE object in > compact serialization i am fine. > > I would also be completely fine with an unsigned "header + content" structure > (though I don't think it adds any value). But it must be recognizably > different from JWS. > > --Richard, who is honestly kind of floored that there's all this argument > over a single "." character > > > > > > John B. > > On 2013-08-19, at 12:30 PM, Justin Richer <[email protected]> wrote: > > > I don't normally jump into the discussion on this list, but I've been using > > the output of JOSE for quite some time now and am a committer on the > > NimbusDS JOSE JWT library. However, with tonight's call coming up (which I > > won't be able to make) I wanted to jump in and say that from my > > perspective, alg:none makes a lot of sense. There's a need for being able > > to send unsigned content with JOSE objects, and that's been pretty well > > established by others on the list here. As an implementor, though, I think > > it makes the most sense to have the unsigned content be parallel in > > structure to the signed content. When reading a string and constructing > > objects, our library parses the header and dispatches the parser based on > > the "alg" parameter. > > > > And as Mike points out, alg:none has been in the spec as required to > > implement for ages now, and it hasn't caused the horrible security holes > > that people are predicting. > > > > -- Justin > > > > On 08/01/2013 07:23 AM, jose issue tracker wrote: > >> #36: Algorithm "none" should be removed > >> > >> > >> Comment (by [email protected]): > >> > >> And sure enough, working groups across the IETF are having to explicitly > >> forbid the use of null ciphersuites. They provide empirical evidence that > >> this design pattern is a bad idea. > >> > >> As I've pointed out before, you can add that verification algorithm, but > >> you will not have a good time writing security considerations around it. > >> Checking that you support "none" is not enough -- you have to check that > >> *nothing* *else* in the header could possibly indicate that a different > >> signature algorithm should be used. > >> > >> So we have something that (1) causes a lot of spec work, (2) causes > >> security vulnerabilities under likely implementaiton designs, and (3) has > >> no use case, and (4) will haunt us for years to come (how many times do > >> you want to write 'MUST NOT use "alg":"none"'?). Sounds like a recipe for > >> success! > >> > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
