Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

["Matt Miller (mamille2)" <[e-mail]>]

To be clear in XMPP, the sender doesn't know the public key of the recipient(s), but does know the address (not name).  XMPP addresses have very specific semantics (RFC 6122), to the point where aliasing has proven to be practically impossible to do.  At the same time, I don't want to be concerned with JOSE-level mismatches because of the addressing semantics.

In my opinion, including "iss" and/or "aud" in JWE doesn't buy XMPP anything, but does introduce a new failure point.  I don't think it's reasonable to expect an XMPP application to store all keys globally.  At most, I expect the key relevant to the user's login would be globally available, but all session keys would be isolated from each other; "kid" should be enough to resolve the proper key.

I'd rather not add something to JWE/JWS unless there's a broader need.  So far I've only seen mention of JWT use cases that need this, and my own which I'm currently not in favor of including.

Personally, I think the pending changes on JWE/JWS/JWK header criticality, as well as a decent registry of parameters (which is defined in JWE, but might need some further definition) means JWT can add these header parameters without impacting all JOSE-using applications.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

On Apr 4, 2013, at 12:52 PM, John Bradley <[e-mail]> wrote:

> I am not against having them as JWE header elements, I have raised the point in several discussions.
> 
> However given that the decryption key is generally already in the hands of the RP it is hard to make the argument that a kid, thumbprint or jwk object are not enough for the recipient to identify what decryption key to use.
> 
> I can see a use in a case like Matt Millers XMPP encryption example where the sender doesn't know the public key of the recipient only its name in that case the recipient won't have the decryption key and needs to know in the unencrypted part of the message who to go and ask for the key.
> 
> I think in the XMPP case the recipient sends its public key and the received "kid" back to the issuer and asks for the decryption key to be encrypted by its public key and sent back.   This is perhaps the sort of thing where having the iss in the unencrypted envelope is a requirement.
> 
> "aud" is also arguably useful if you have a multi hop situation where the client needs to make a forwarding decision without creating yet another level of wrapping for the token.
> 
> So I do see uses for them.  
> 
> I do agree with Mike that it may be best to use the definitions in JWT and have the processing rule about what happens if you get the claim in the header and in the body or if it is only in the header laid out there.   
> 
> The thing that is important in a JWE context is if those claims are going to be integrity protected.   There is continued debate about removing the envelope from the integrity protection.  That is a JWE issue.   I also think if they are in JWT as being allowed in the JWE header referencing that from JWE is not a bad thing. 
> 
> John B.
> 
> 
> On 2013-04-04, at 1:32 PM, Mike Jones <[e-mail]> wrote:
> 
>> Responding to your "unsettled" remark, I suspect most people are fine with having the "aud" and "iss" be claims in the JWT where they normally are.  Yes, you have to decrypt the token to get these claim values, but if you're going to use the token, you'll have to do that anyway.
>> 
>> I don't think it's clear to most people what problem is being solved by potentially these fields to be present in a different location.  Without a compelling use case, this just seems like more to implement without a clear benefit of doing so.
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: Dick Hardt [mailto:[e-mail]] 
>> Sent: Wednesday, April 03, 2013 9:29 PM
>> To: jose issue tracker
>> Cc: [e-mail]; Mike Jones; [e-mail]; [e-mail]
>> Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names
>> 
>> Actually, Mike was suggesting that the issue be moved to the JWT WG. 
>> 
>> I'll settle with the JWE spec pointing to an IANA registry. Speaking as an implementer, if there is a list of reserved names in the spec, I'm likely to think that is all of them.
>> 
>> I'm a little unsettled that no one else has had any feedback on having 'aud' and 'iss' in the JWE header. Is my implementation the only that has that requirement? 
>> 
>> -- Dick
>> 
>> On Apr 3, 2013, at 8:57 PM, "jose issue tracker" <[e-mail]> wrote:
>> 
>>> #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names
>>> 
>>> 
>>> Comment (by [e-mail]):
>>> 
>>> I agree with Mike that these don't really belong in the core JWE/JWS 
>>> specs.
>>> 
>>> I would suggest we address this issue more generally, by creating an 
>>> IANA registry of reserved parameter names, with a fairly liberal 
>>> inclusion policy.  That registry could have a field to indicate 
>>> whether JOSE implementations are REQUIRED to support a given parameter 
>>> (MTI parameters).  (Note that this is different from whether a JOSE 
>>> object is REQUIRED to contain a parameter.)  Perhaps we could have 
>>> optional parameters under a fairly liberal policy (e.g., Specification 
>>> Required), with a higher bar for MTI parameters (e.g., Standards Action).
>>> 
>>> If we set up the registry in this way, then Dick could write a short 
>>> Informational document that would register these fields.
>>> 
>>> --
>>> -------------------------+--------------------------------------------
>>> -------------------------+-----
>>> Reporter:               |       Owner:  draft-ietf-jose-json-web-
>>> [e-mail]   |  [e-mail]
>>>   Type:  enhancement  |      Status:  new
>>> Priority:  major        |   Milestone:
>>> Component:  json-web-    |     Version:
>>> encryption             |  Resolution:
>>> Severity:  -            |
>>> Keywords:               |
>>> -------------------------+--------------------------------------------
>>> -------------------------+-----
>>> 
>>> Ticket URL: 
>>> <http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:2>
>>> jose <http://tools.ietf.org/jose/>
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose