Re: [jose] TTL for JWK

["Manger, James H" <[e-mail]>]

> I don't believe the must-understand requirement applies to JWK as the drafts are currently written, does it?

It certainly does.
draft-ietf-jose-json-web-key-08 section 4 “JSON Web Key (JWK) Format”.

   Additional members MAY be present in the JWK.  If present, they MUST
   be understood by implementations using them.

--
James Manger

From: Brian Campbell [mailto:[e-mail]]
Sent: Thursday, 21 February 2013 1:37 AM
To: Manger, James H
Cc: [e-mail]
Subject: Re: [jose] TTL for JWK

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]<mailto:[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]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian Campbell
Sent: Tuesday, February 19, 2013 3:43 PM
To: [e-mail]<mailto:[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