Re: [jose] TTL for JWK

John Bradley <ve7jtb@ve7jtb.com> Wed, 20 February 2013 03:14 UTC

Return-Path: <ve7jtb@ve7jtb.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 39C2721F88B9 for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 19:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.462
X-Spam-Level:
X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 PJFSGRqWd77p for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 19:14:10 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id EA24721F88C4 for <jose@ietf.org>; Tue, 19 Feb 2013 19:14:07 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id z4so2206195qan.12 for <jose@ietf.org>; Tue, 19 Feb 2013 19:14:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=khEpj3KJvPF/bYd3wyaV38goezME2B5mhSs1d9MNxTc=; b=LUPB44Ish47eIUcnIKadF8FXSW0VhtUcLrA0ZCuwgzJ1+rLpkDC0ZXi7G2tH6dHfbC WoVoKTpmC4qM5ijhddc+ZsV3sB8iibYA6UeBf90+QumT+RoBby/aG9gU2I39Y6Topl1O xmxV/ZHgp//0/qLLtNCEs0uK5gsdKTWG1jRunhcH5dYBWkPevsaiAUhayHkJyKtcS6BW reDe26lDfcoHH2D/6FoRDoYT9VO2Rj4Iqaa8uXyjJxOux5Jl6X5cOt6/9oz/cpvQe37T CkdndBSQdGRlMf6wukSZ4+orJ5VUUTkE7OtdxqCviLcpTWyVK2DLjUZ9kHylvJRVCxXa FAaw==
X-Received: by 10.224.40.16 with SMTP id i16mr8685274qae.48.1361330047088; Tue, 19 Feb 2013 19:14:07 -0800 (PST)
Received: from [192.168.1.213] (190-20-4-185.baf.movistar.cl. [190.20.4.185]) by mx.google.com with ESMTPS id s6sm10043509qaz.13.2013.02.19.19.13.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 19:14:05 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E7855AC7-6E2F-4A10-AEA5-2E86CE75879C"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CA+k3eCTbKzWaSr0cmSKTgfs2WMwfGjxatCMjFJekf+8E5SRjXQ@mail.gmail.com>
Date: Wed, 20 Feb 2013 00:12:32 -0300
Message-Id: <84EEBC7B-1C68-485E-998D-D01CAE884675@ve7jtb.com>
References: <CA+k3eCTZ4KeC7ZH41OWkjkLCp0RiRBkze=4NpFO7AG5zVq-bJQ@mail.gmail.com> <4E1F6AAD24975D4BA5B168042967394367477CB0@TK5EX14MBXC284.redmond.corp.microsoft.com> <CA+k3eCTbKzWaSr0cmSKTgfs2WMwfGjxatCMjFJekf+8E5SRjXQ@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmfY96UxeZaUN25cbjsbsq8txkZVW+dw6Go8lfpRXviwoE6LJRT5WRlrcjq5CGjri7R0Lcs
Cc: Mike Jones <Michael.Jones@microsoft.com>, "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 03:14:11 -0000

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 <bcampbell@pingidentity.com> 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 <Michael.Jones@microsoft.com> 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
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose