Re: [jose] TTL for JWK

Brian Campbell <> Wed, 20 February 2013 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B818D21F87E4 for <>; Wed, 20 Feb 2013 06:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LazGhg1mY-lx for <>; Wed, 20 Feb 2013 06:37:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6541721F87E0 for <>; Wed, 20 Feb 2013 06:37:48 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 20 Feb 2013 06:37:48 PST
Received: by with SMTP id o6so40969828oag.10 for <>; Wed, 20 Feb 2013 06:37:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=1jY4SusG5gNzxDdlG4nqU1L41xSJrmaR4nw/BgFrmtk=; b=akNm4l2ON1pYlowUBrLMemQKW3A8z7dh52O/Ry/SweG6+LToy3ujXBSB1HH7zCHeHc a1vZ0885Va52jLZp+8MaUk7sPzlVP3S9aXEglR7SNkaKHxJaGzDgCBghSfpTJiGV1LYU fAlh0PuWT8UOl/CpC5FuWZV3XeEYm/oxkGT7CX/MKWCID0W3PUs7I2q1HdvDd/aQ9kfp OgYuaJnXdHzYtpcHJIb/R01WP26mDJbyskyo1EQgj6IG0+C9WS/Rputbp9r39OyjMozP pLiQ8cTpCr8G6GAWtQJ4P6Q5yXS97WKRaPwOYJZMox01sYLFfhNuOBXh56Til+5CnjFy Cwag==
X-Received: by with SMTP id t5mr11323544igb.65.1361371067428; Wed, 20 Feb 2013 06:37:47 -0800 (PST)
X-Received: by with SMTP id t5mr11323541igb.65.1361371067292; Wed, 20 Feb 2013 06:37:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Feb 2013 06:37:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Brian Campbell <>
Date: Wed, 20 Feb 2013 07:37:17 -0700
Message-ID: <>
To: "Manger, James H" <>
Content-Type: multipart/alternative; boundary=e89a8f646d15df9b5404d628e675
X-Gm-Message-State: ALoCoQmLsx+Q+l4JFIvmKF2luXk/lS/uJ9kdwj/RwdEIbwmBxzzYQ7VoTqM4VDqK/e+GaGQc/ncIqL/++DKyoBWnbonQfgvwoPGDnOYQEGMgoskVBRtnPwO2SDHKbJjTQ+k8xzrwo++Q
Cc: "" <>
Subject: Re: [jose] TTL for JWK
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2013 14:37:49 -0000

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