Re: [jose] TTL for JWK

Brian Campbell <> Wed, 20 February 2013 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 800B621F85F5 for <>; Tue, 19 Feb 2013 16:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.027, 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 ZCSrOaXipNJC for <>; Tue, 19 Feb 2013 16:27:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3973721F8818 for <>; Tue, 19 Feb 2013 16:27:26 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUSQYbVuZz48lWX2XM4rx/; Tue, 19 Feb 2013 16:27:26 PST
Received: by with SMTP id q16so8585214bkw.4 for <>; Tue, 19 Feb 2013 16:27:24 -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=imk6R1LA+YdbQe0mfDc2UwZLvS8WwBD5kuZEYFyhlJ4=; b=UA/yzHoa/zbPu7uv59Bq6Naop6VQjmB7PZ7S6HBxac31KFzp00qCtzkafVN3NHHLcK nEmrJ9vFnMUuL5cD+giGAKRADTtNzIciJxM5yjnTuBsKkRtAb9Kuh/alTIGpzqg5KRaZ 532DUCcx+2B+xxjBGqYFeJRqTaR8OmfTuLqiO2NOUNJ86URWfBJ1hQqLqxVm6tkd6oP1 NWUSx0T/w7hJelxVhR2oXG1Idxi/2maqMSNwGeI1Pnj18or/l3+3Hs+dJN1dYV1NIKaq bak+RC8E3hrtaIS1rmxtctss86Jo1kwX1hVilWaAg8ssQq858RtyoOvihYA4yG4haQRM LyIA==
X-Received: by with SMTP id q46mr63052657eem.1.1361320044443; Tue, 19 Feb 2013 16:27:24 -0800 (PST)
X-Received: by with SMTP id q46mr63052637eem.1.1361320044263; Tue, 19 Feb 2013 16:27:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 19 Feb 2013 16:26:54 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Tue, 19 Feb 2013 17:26:54 -0700
Message-ID: <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary=047d7b344142a9faae04d61d05fa
X-Gm-Message-State: ALoCoQnX7eTG6KMZM3O/of9Ev+AHOrCXaqbWfEVmwk7Dzrug9VCPnw1GbG2CakOru2pPIfAXoGBGpa0p1dVve5C4qbMEXarnCgB1J0Mr/bsVR4ePxRokfcQnsAlk1iv+fMRyq+3etglV
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 00:27:27 -0000

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 <>wrote;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:* [] *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]
> *
> _______________________________________________
> jose mailing list