Re: [jose] TTL for JWK

Brian Campbell <bcampbell@pingidentity.com> Wed, 20 February 2013 00:27 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B621F85F5 for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 16:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCSrOaXipNJC for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 16:27:26 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3973721F8818 for <jose@ietf.org>; Tue, 19 Feb 2013 16:27:26 -0800 (PST)
Received: from mail-bk0-f69.google.com ([209.85.214.69]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUSQYbVuZz48lWX2XM4rx/ldXUf2nBKW6@postini.com; Tue, 19 Feb 2013 16:27:26 PST
Received: by mail-bk0-f69.google.com with SMTP id q16so8585214bkw.4 for <jose@ietf.org>; Tue, 19 Feb 2013 16:27:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.14.183.198 with SMTP id q46mr63052657eem.1.1361320044443; Tue, 19 Feb 2013 16:27:24 -0800 (PST)
X-Received: by 10.14.183.198 with SMTP id q46mr63052637eem.1.1361320044263; Tue, 19 Feb 2013 16:27:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.173.9 with HTTP; Tue, 19 Feb 2013 16:26:54 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477CB0@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <CA+k3eCTZ4KeC7ZH41OWkjkLCp0RiRBkze=4NpFO7AG5zVq-bJQ@mail.gmail.com> <4E1F6AAD24975D4BA5B168042967394367477CB0@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 19 Feb 2013 17:26:54 -0700
Message-ID: <CA+k3eCTbKzWaSr0cmSKTgfs2WMwfGjxatCMjFJekf+8E5SRjXQ@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=047d7b344142a9faae04d61d05fa
X-Gm-Message-State: ALoCoQnX7eTG6KMZM3O/of9Ev+AHOrCXaqbWfEVmwk7Dzrug9VCPnw1GbG2CakOru2pPIfAXoGBGpa0p1dVve5C4qbMEXarnCgB1J0Mr/bsVR4ePxRokfcQnsAlk1iv+fMRyq+3etglV
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] TTL for JWK
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=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 <Michael.Jones@microsoft.com>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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Brian Campbell
> *Sent:* Tuesday, February 19, 2013 3:43 PM
> *To:* jose@ietf.org
> *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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>