So, once I've figured out what serialization I'm in and whether I'm in a JWE or JWS, I can use "alg" to determine whether I'm in a JWE or JWS. Handy!
I would also point out that Phil's suggestion *doesn't* break this invariant, since you would interpret "alg":"none" to do no further processing. On Mon, Aug 19, 2013 at 4:38 PM, Mike Jones <[email protected]>wrote: > It still holds. Once you determine the Header Parameter values (a > process that is admittedly serialization-specific), you use the “alg” value > in all cases to determine what operations to perform for that recipient.** > ** > > ** ** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Monday, August 19, 2013 1:35 PM > *To:* Mike Jones > *Cc:* Phil Hunt; John Bradley; jose issue tracker; Justin Richer; > [email protected]; [email protected] > > *Subject:* Re: [jose] #36: Algorithm "none" should be removed**** > > ** ** > > Too bad that "invariant" is already broken by the existence of the JSON > serialization, etc. You can't even find the header unless you know whether > you're looking at JSON or compact, and if JSON, JWS or JWE. Heck, in a > multi-recipient JWE, there's not even an "alg" parameter at the top level. > **** > > ** ** > > On Mon, Aug 19, 2013 at 4: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] <[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
