Re: [jose] TTL for JWK

Richard Barnes <rlb@ipv.sx> Wed, 20 February 2013 23:33 UTC

Return-Path: <rlb@ipv.sx>
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 D9DAF21E8037 for <jose@ietfa.amsl.com>; Wed, 20 Feb 2013 15:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mS2UcKVYKEyS for <jose@ietfa.amsl.com>; Wed, 20 Feb 2013 15:33:18 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAE921F841C for <jose@ietf.org>; Wed, 20 Feb 2013 15:33:18 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id o6so8734654oag.32 for <jose@ietf.org>; Wed, 20 Feb 2013 15:33:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CZj9K3RwzArCBhgjkfCrV9ftPfLmE7L+JGqDbhu1x9U=; b=MpaWlpayfyVCwQnpn5xKUzUFxuZHGHkmbmYoEaRFgGdgBT7k2GFbcV8OD1gAKz8ipO I+xBVtxrG7FVywclM3jbCVOBlmd3KRnl78XkkoPEdywd6y1hDDOyZfGO6Ek8Rj8KTVMk NR63x0Q1Lgcq42zvWOWeclhpXCm28iZPLEElYv9FSc+cONSD8JyyxcyXhR47nBfR2Ylk MwDjz5Xu2aIF+HyGHYjlhb/jGbS4AdlD/VMPNQrU5vXmQiiwXiMhhsqwPMhpOu2OKB3K gbJKP88UwAekQEbXgv9wrd/bgD9PYjI9/pQXtlz8iQkxtZQ69QNsHk5R7i+IerOokCTM e4rA==
MIME-Version: 1.0
X-Received: by 10.182.190.97 with SMTP id gp1mr10154714obc.19.1361403194810; Wed, 20 Feb 2013 15:33:14 -0800 (PST)
Received: by 10.60.60.98 with HTTP; Wed, 20 Feb 2013 15:33:14 -0800 (PST)
X-Originating-IP: [174.237.33.93]
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11507634D16@WSMSG3153V.srv.dir.telstra.com>
References: <CA+k3eCTZ4KeC7ZH41OWkjkLCp0RiRBkze=4NpFO7AG5zVq-bJQ@mail.gmail.com> <4E1F6AAD24975D4BA5B168042967394367477CB0@TK5EX14MBXC284.redmond.corp.microsoft.com> <CA+k3eCTbKzWaSr0cmSKTgfs2WMwfGjxatCMjFJekf+8E5SRjXQ@mail.gmail.com> <84EEBC7B-1C68-485E-998D-D01CAE884675@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E115076349DB@WSMSG3153V.srv.dir.telstra.com> <CA+k3eCR4eX7fk3ibra97hcJ9jpEMWxhJZhb4E2RFbSP8ogui9A@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11507634D16@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 20 Feb 2013 18:33:14 -0500
Message-ID: <CAL02cgSG=rt27n5Lq1nfYGS+dXNALM+JpxmC=UpD-5388BzLwg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary=f46d0444e849d2a12804d6306114
X-Gm-Message-State: ALoCoQmMXejT4QiTW5aRKCo+xe9XiJcm1So72hPj5QMQXp/QWa69iHyEGDHWOtPwLDbIVUpqH98C
Cc: Brian Campbell <bcampbell@pingidentity.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 23:33:20 -0000

+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:bcampbell@pingidentity.com<javascript:_e({}, 'cvml', 'bcampbell@pingidentity.com');>]
>
> *Sent:* Thursday, 21 February 2013 1:37 AM
> *To:* Manger, James H
> *Cc:* jose@ietf.org <javascript:_e({}, 'cvml', 'jose@ietf.org');>
> *Subject:* Re: [jose] TTL for JWK****
>
> ** **
>
> 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 <
> James.H.Manger@team.telstra.com> 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 <bcampbell@pingidentity.com>
> 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:* 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-tok<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-2>
>