Re: [jose] TTL for JWK

Richard Barnes <rlb@ipv.sx> Thu, 21 February 2013 14:11 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 2AE7621F8BE4 for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 06:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.684
X-Spam-Level:
X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=0.292, 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 bzQUfsj2rp5W for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 06:11:52 -0800 (PST)
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8921F8AC3 for <jose@ietf.org>; Thu, 21 Feb 2013 06:11:52 -0800 (PST)
Received: by mail-ob0-f173.google.com with SMTP id dn14so8924594obc.32 for <jose@ietf.org>; Thu, 21 Feb 2013 06:11:51 -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=6jaJ6obH/kBZ7RjGZ0oOoKIe8/NPkgalRcGgKP3I9Kg=; b=hKHK11AuvoMnDx652QLA2Wp/rOhYjzMJ1XinAQ+aOsCODeKvBYgEkvUF0VdN5Ivn9F OU3XgLeUGeLUCj+6puitjU3GBlukNEp/z+/e+oQI3s/xusDj6W1XZpcIZxHlTkucCkbr RbBQRReJxaXrYzd/YsqddrhZVwopa7M9PkOjkNqZq+TPfkto4BdSC/TtoZRQ9o/uzM61 jrCHViS3Cv/t016tZDfyOMB1Yg0ew7RFzdh+b+WYEakiYVEwh//t+/+cJ5IXRfOZ9ARh 3g6A0Bm5xZQKcZcBr7sRq1SkLrHL2caO1IsEnlT3Sb274UUNrmF685OphNfHprY21vm2 WuIw==
MIME-Version: 1.0
X-Received: by 10.60.1.129 with SMTP id 1mr10734641oem.93.1361455911612; Thu, 21 Feb 2013 06:11:51 -0800 (PST)
Received: by 10.60.60.98 with HTTP; Thu, 21 Feb 2013 06:11:51 -0800 (PST)
X-Originating-IP: [192.1.51.63]
In-Reply-To: <CA+k3eCQsratusrRNPv6hZG-mCsswx_sCKj=SqjfwP+vkAKxGZQ@mail.gmail.com>
References: <CA+k3eCTZ4KeC7ZH41OWkjkLCp0RiRBkze=4NpFO7AG5zVq-bJQ@mail.gmail.com> <5124E39C.2030804@oracle.com> <CA+k3eCSGPfpUbeBkSCMTh+jAJgxMP8BWsgdLPt_CqsvkaXASCQ@mail.gmail.com> <CAL02cgShtAZssKzX_jiTroFczsepG=d=QaV_8=1kYoTk9UiHmg@mail.gmail.com> <CA+k3eCQsratusrRNPv6hZG-mCsswx_sCKj=SqjfwP+vkAKxGZQ@mail.gmail.com>
Date: Thu, 21 Feb 2013 09:11:51 -0500
Message-ID: <CAL02cgSwBUGYcdHRRkDMRh7WCFfVBk7JjZVa2RVw-R+GY6=5nw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f4f4fd30a204d63ca78f
X-Gm-Message-State: ALoCoQkc5eeubYOYOdBHEevw0tC5mSDxDL8o5Ubcxkvd1CODmHSYSfF+Y7zm81WexAjjKXfRFAMf
Cc: "jose@ietf.org" <jose@ietf.org>, Prateek Mishra <prateek.mishra@oracle.com>
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: Thu, 21 Feb 2013 14:11:57 -0000

One thing to note, though: If all fields weren't critical, then Brian could
just add this to his JWKs and the parsers wouldn't choke.  This is actually
a nice example of a non-critical field.

Thanks,
--Richard



On Wed, Feb 20, 2013 at 6:58 PM, Brian Campbell
<bcampbell@pingidentity.com>wrote;wrote:

> I was specifically trying to avoid "creeping back toward X.509" and that
> was a big part of the distinction I was trying to make in calling it TTL
> and treating it as some kind of cache duration hint while not wanting it to
> be a hard expiration date that had to be validated.
>
> But, again, I think it's moot because I've been swayed here into thinking
> that this proposal isn't fully baked and that I can use other means to
> address the immediate problem I'm trying to solve.
>
> Thanks to everyone for the input though. It's been valuable (to me at
> least) to help clarify some thinking around these concepts.
>
>
> On Wed, Feb 20, 2013 at 4:24 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
>> Yeah, even after reading the thread, this proposal seems really unclear.
>>
>> Now, my first thought on reading Brian's initial mail was, "oh, it looks
>> like we're creeping back toward X.509!"  Which I don't mean as a bad thing.
>>  After all, a lot of the fields we already have in JWK are analogous to
>> PKIX fields, and what are certificates but a key, some attributes, and a
>> signature over that package.  If we were going to go down that path
>> (PKIJ?), then this sort of attribute would completely make sense,
>> especially if it were phrased as an absolute time, like the PKIX notAfter.
>>
>> But if we are going to go down that path, I think we need a recharter...
>>
>> --Richard
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 20, 2013 at 10:19 AM, Brian Campbell <
>> bcampbell@pingidentity.com> wrote:
>>
>>> A fair question Prateek, but if you take that to it's logical end, it
>>> might suggest that "use", "kid" and "alg" be removed from JWK as well.
>>>
>>> But my resolve for this proposal is weakening so it's not worth arguing
>>> about.
>>>
>>>
>>> On Wed, Feb 20, 2013 at 7:54 AM, Prateek Mishra <
>>> prateek.mishra@oracle.com> wrote:
>>>
>>>>  Shouldn't this be a part of a key management layer distinct from JWK?
>>>>
>>>> I was under the impression that JWK was limited to
>>>>
>>>> [quote]
>>>>
>>>>
>>>>
>>>> JavaScript Object Notation (JSON) data
>>>>    structure that represents a public key.  This specification also
>>>>    defines a JSON Web Key Set (JWK Set) JSON data structure for
>>>>    representing a set of JWKs.
>>>>
>>>> [\quote]
>>>>
>>>> - prateek
>>>>
>>>> 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 listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>