Re: [jose] TTL for JWK

[John Bradley <[e-mail]>]

I don't think that JWK itself  has a MUST understand.

If you are including a JWK in the header of a JWE for say ECDH-ES then that element (the JWK content of epk) needs to be understood by the recipient.   

I think the question of how MUST understand applies to elements of a top level claims probably needs more clarification once we get over the poll.

I don't know that ttl as part of epk is sensible,  perhaps exp might make sense but including ether of them in epk is probably mot helpful.

The limitation of the http caching approach is that it requires a pull,  but logically if the endpoint is going to do something to refresh the key it needs to have something to pull from.

Now what I don't know is if in Matt's work using xmpp if there is a need for a refresh mechanism to refresh encryption keys, that can't use http caching.

John B.





On 2013-02-20, at 11:37 AM, Brian Campbell <[e-mail]> wrote:

> To Mike's comment on the ttl of an IP packet - I did extensive research on wikipedia that suggests a TTL can either be a counter or a time-stamp. The idea is the same - discard or stop using at such and such a point. TTL may not be right but it seemed closer than exp for what I was aiming for.
> 
> To James and John's comment on JWK Set and HTTP, I was thinking a per key usage but the way I was envisioning it does ultimately result in the whole JWK Set being refreshed (re-fetched?) and that would argue for it being at the JWK Set level. And yeah, at that point it'd make sense to just use HTTP cache control. I'd been trying to avoid that because of a suspicion that the HTTP headers would likely be set wrong or ignored by some. But using that as a justification to reinvent the concept at another layer sounds rather silly when I say (er type) it out loud. So, I dunno, maybe this isn't such a great idea after all and using HTTP level caching mechanisms to address my particular problem is a better approach.  
> 
> To James' other comment on "MUST-understand-everything" - I don't always answer rhetorical questions in a public forum but, what the heck, it'd be more than just awkward. It'd be darn near impossible for any deployments that had more than just single bilateral relationships. You're point is taken (though I already fall in the not-MUST-understand camp) but I don't believe the must-understand requirement applies to JWK as the drafts are currently written, does it?
> 
> 
> 
> 
> 
> 
> 
> On Wed, Feb 20, 2013 at 5:27 AM, Manger, James H <[e-mail]> wrote:
> This feature sounds so close in function to an HTTP Cache-Control header. Surely we can just use this existing mechanism? Particularly as the real use case mentioned in getting a JWK from an HTTPS URI.
> 
>  
> 
>  
> 
> P.S. If we do defer specifying “TTL for JWK” now, but after a few years experience of rolling keys in OpenID Connect decide it would be good, then I wonder how awkward deploying it would be due to the MUST-understand-everything rule?
> 
>  
> 
> --
> 
> James Manger
> 
>  
> 
> On 2013-02-19, at 9:26 PM, Brian Campbell <[e-mail]> wrote:
> 
>  
> 
> …this was more of a indicator about how long a key could be cached/used with a reasonable expectation that things would still work… 
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Brian Campbell
> Sent: Tuesday, February 19, 2013 3:43 PM
> To: [e-mail]
> Subject: [jose] TTL for JWK
> 
> I'd like to float the idea of introducing a time to live parameter to the base JWK document, which could probably fit in as a subsection of §4 that defines parameters common to all key types [1].
> 
> The motivation is that many uses of JWKs will involve caching of JWK data and a TTL parameter could be used to indicate how long a key could be safely cached and used without needing to recheck the JWK source. I don't want it to be a hard expiration date for the key but rather a hint to help facility efficient and error free caching.
> 
> OpenID Connect has a real use case for this where entities publish their keys via a JWK Set at an HTTPS URL. To support key rotation and encryption, there needs to be some way to indicate the TTL of a public key used to encrypt. Of course, this isn't the only way to skin that cat but it strikes me as a good way and one that might provide utility for JWK in other contexts.
> JSON Web Token [2] defines a data type that is "A JSON numeric value representing the number of seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time" that seems like it could be co-opted to work well as the value for a "ttl" parameter.
> 
> [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08#section-4
> 
> [2] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2
> 
>  
> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose