Subject: [jose] TTL for JWK

From: Brian Campbell <[email-masked]>
Date: Tue, 19 Feb 2013 16:43:29 -0700

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 00:04:20 +0000

Is this a key expiration time parameter or is there a subtle distinction that I'm missing?  If it is an expiration time, I'd recommend that if we do this, that we reuse the name "exp" from the JWT spec.  (We actually stopped using this name as an RSA parameter name a few drafts ago exactly so we could use it for this purpose.)

                                                            -- Mike

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 19 Feb 2013 17:26:54 -0700

The subtle (and maybe unimportant) distinction I was trying to make was
that this was more of a indicator about how long a key could be cached/used
with a reasonable expectation that things would still work. I tend to think
of key expiration as being something more like any use of the key after the
time should be considered invalid. I wanted to avoid requiring message
rejection if expiration checks failed (as is the case with exp in JWT).  I
remember the change to RSA to free up "exp" and was going to propose just
using that. But after thinking about it a bit, to me anyway, "ttl" conveyed
that idea better than "exp." I'd be fine with either parameter name though.

Does that make sense?

On Tue, Feb 19, 2013 at 5:04 PM, Mike Jones <[email-masked]>wrote:

>  Is this a key expiration time parameter or is there a subtle distinction
> that I’m missing?  If it is an expiration time, I’d recommend that if we do
> this, that we reuse the name “exp” from the JWT spec.  (We actually stopped
> using this name as an RSA parameter name a few drafts ago exactly so we
> could use it for this purpose.)****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Campbell
> *Sent:* Tuesday, February 19, 2013 3:43 PM
> *To:* [email-masked]
> *Subject:* [jose] TTL for JWK****
>
> ** **
>
> [2]
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2***
> *
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2013 00:12:32 -0300

Yes ttl and exp are different.    ttl probably should apply to a JWK set as a whole rather than the individual JWK where exp is certainly a per key value.

Mike, this is a bit like the distinction in DNS.

John B.

On 2013-02-19, at 9:26 PM, Brian Campbell <[email-masked]> wrote:

> The subtle (and maybe unimportant) distinction I was trying to make was that this was more of a indicator about how long a key could be cached/used with a reasonable expectation that things would still work. I tend to think of key expiration as being something more like any use of the key after the time should be considered invalid. I wanted to avoid requiring message rejection if expiration checks failed (as is the case with exp in JWT).  I remember the change to RSA to free up "exp" and was going to propose just using that. But after thinking about it a bit, to me anyway, "ttl" conveyed that idea better than "exp." I'd be fine with either parameter name though.
> 
> Does that make sense?
> 
> 
> On Tue, Feb 19, 2013 at 5:04 PM, Mike Jones <[email-masked]> wrote:
> Is this a key expiration time parameter or is there a subtle distinction that I’m missing?  If it is an expiration time, I’d recommend that if we do this, that we reuse the name “exp” from the JWT spec.  (We actually stopped using this name as an RSA parameter name a few drafts ago exactly so we could use it for this purpose.)
> 
>  
> 
>                                                             -- Mike
> 
>  
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 20 Feb 2013 03:21:32 +0000

I think applying the ttl to the individual JWK makes more sense.  I can definitely see where a JWK set would hold one key, then be updated with a new alternate (roll-over) key with a long ttl (since it's the new replacement) but with a short ttl on the original (because it's going to actually go live any day/minute/second now).  When the new key is fully deployed, the JWK set is updated to remove it.

As with implied comparisons to DNS, the ttl there is on the individual resource records, not the entire answer.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2013 00:37:06 -0300

Sorry I was thinking of the caching for secondary servers rather than the per record ttl.  I suppose DNS has both.

If a jku contains a set is the caching the shortest value?   I am not against doing it per jwk as that is potentially more flexible and avoids a new element in jwk set.

If we were only talking about jku files then http caching might work, but has limitations.

John B.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 20 Feb 2013 23:27:29 +1100

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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Feb 2013 07:37:17 -0700

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 <
[email-masked]> 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 <[email-masked]>
> 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: Prateek Mishra <[email-masked]>
Date: Wed, 20 Feb 2013 09:54:20 -0500

Shouldn't this be a part of a key management layer distinct from JWK?

I was under the impression that JWK was limited to

[quote]

JavaScript Object Notation (JSON) data
    structure that represents a public key.  This specification also
    defines a JSON Web Key Set (JWK Set) JSON data structure for
    representing a set of JWKs.

[\quote]

- prateek
> 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.
> 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.
>
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Feb 2013 12:08:21 -0300

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 <[email-masked]> 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 <[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Feb 2013 08:19:41 -0700

A fair question Prateek, but if you take that to it's logical end, it might
suggest that "use", "kid" and "alg" be removed from JWK as well.

But my resolve for this proposal is weakening so it's not worth arguing
about.

On Wed, Feb 20, 2013 at 7:54 AM, Prateek Mishra
<[email-masked]>wrote:

> jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Feb 2013 18:24:02 -0500

Yeah, even after reading the thread, this proposal seems really unclear.

Now, my first thought on reading Brian's initial mail was, "oh, it looks
like we're creeping back toward X.509!"  Which I don't mean as a bad thing.
 After all, a lot of the fields we already have in JWK are analogous to
PKIX fields, and what are certificates but a key, some attributes, and a
signature over that package.  If we were going to go down that path
(PKIJ?), then this sort of attribute would completely make sense,
especially if it were phrased as an absolute time, like the PKIX notAfter.

But if we are going to go down that path, I think we need a recharter...

--Richard

On Wed, Feb 20, 2013 at 10:19 AM, Brian Campbell <[email-masked]

> A fair question Prateek, but if you take that to it's logical end, it
> might suggest that "use", "kid" and "alg" be removed from JWK as well.
>
> On Wed, Feb 20, 2013 at 7:54 AM, Prateek Mishra <[email-masked]
> > wrote:
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Feb 2013 10:30:52 +1100

> 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:[email-masked]]
Sent: Thursday, 21 February 2013 1:37 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [jose] TTL for JWK

On Wed, Feb 20, 2013 at 5:27 AM, Manger, James H <[email-masked]<mailto:[email-masked]>> 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.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Feb 2013 18:33:14 -0500

+1 for removing that one too.

On Wednesday, February 20, 2013, Manger, James H wrote:

> > 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:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
>
> *Sent:* Thursday, 21 February 2013 1:37 AM
> *To:* Manger, James H
> *Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> *Subject:* Re: [jose] TTL for JWK****
>
> ** **
>
> not be right but it seemed closer than exp for what I was aiming for.****
>
> to address my particular problem is a better approach.  ****
>
> ****
> [email-masked]> wrote:****
>
>  ****
>  ****
>  ****
>  ****
>  ****
> [2] http://tools.ietf.org/html/draft-ietf-oauth-json-web-tok<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Feb 2013 16:58:53 -0700

I was specifically trying to avoid "creeping back toward X.509" and that
was a big part of the distinction I was trying to make in calling it TTL
and treating it as some kind of cache duration hint while not wanting it to
be a hard expiration date that had to be validated.

But, again, I think it's moot because I've been swayed here into thinking
that this proposal isn't fully baked and that I can use other means to
address the immediate problem I'm trying to solve.

Thanks to everyone for the input though. It's been valuable (to me at
least) to help clarify some thinking around these concepts.

On Wed, Feb 20, 2013 at 4:24 PM, Richard Barnes <[email-masked]> wrote:

> On Wed, Feb 20, 2013 at 10:19 AM, Brian Campbell <
> [email-masked]> wrote:
>
>> On Wed, Feb 20, 2013 at 7:54 AM, Prateek Mishra <
>> [email-masked]> wrote:
>>
>>> the base JWK document, which could probably fit in as a subsection of §4
>>> that defines parameters common to all key types [1].
>>>
>>> data and a TTL parameter could be used to indicate how long a key could be

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Feb 2013 17:03:20 -0700

Doh, you got me with an RTFID!  ;)

I guess it's safe to say my nascent JOSE implementation doesn't enforce the
MUST-understand for JWK. Actually, it doesn't for anything at the moment.
For whatever that's worth...

---

From: Richard Barnes <[email-masked]>
Date: Thu, 21 Feb 2013 09:11:51 -0500

One thing to note, though: If all fields weren't critical, then Brian could
just add this to his JWKs and the parsers wouldn't choke.  This is actually
a nice example of a non-critical field.

Thanks,
--Richard

On Wed, Feb 20, 2013 at 6:58 PM, Brian Campbell
<[email-masked]>wrote:

>>>> 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.
>>>> [1]
>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08#section-4
>>>>
>>>> [2]