Yes information like issuer may be present in the header as is allowed by JWT.
In one case the body is a binary blob and all the information iss aud etc are in the header. The same payload may also be sent signed to allow the receiver to verify the object before it is sent off for introspection to avoid denial of service attacks on the introspection endpoint. So the receiver may or may not allow alg none based on the iss. In the common case of the openID request object the client specifies during registration what algorithm must be used to validate it's requests. Some clients want to use the JSON request format but don't care about integrity protecting the request, others doing higher LOA may need to sign or encrypt requests for non repudiation and privacy. In Connect currently the format of the request is the same in that it is a JWT that can be signed unsigned or encrypted. John B. On 2013-08-19, at 5:10 PM, "Jim Schaad" <[email protected]> wrote: > John, > > In these cases are you carrying information in the JWS object other than the > algorithm? I am trying to figure out if the "protected header" field is > really used in this case. > > Jim > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> John Bradley >> Sent: Monday, August 19, 2013 12:49 PM >> To: Justin Richer >> Cc: [email protected]; [email protected]; jose issue tracker; >> [email protected]; [email protected] >> Subject: Re: [jose] #36: Algorithm "none" should be removed >> >> 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. >> >> What we call it I am flexible about, if it is a unsigned JOSE object in > compact >> serialization i am fine. >> >> 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
