Re: [jose] TTL for JWK

Brian Campbell <bcampbell@pingidentity.com> Wed, 20 February 2013 23:59 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 97C5C21F8C4F for <jose@ietfa.amsl.com>; Wed, 20 Feb 2013 15:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.952
X-Spam-Level:
X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.024, 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 RRMNKDaWwiTu for <jose@ietfa.amsl.com>; Wed, 20 Feb 2013 15:59:25 -0800 (PST)
Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6261221F8C51 for <jose@ietf.org>; Wed, 20 Feb 2013 15:59:25 -0800 (PST)
Received: from mail-ob0-f200.google.com ([209.85.214.200]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKUSVjXCJYB9Z8nOb9GpOJJV/D9lP0Px2H@postini.com; Wed, 20 Feb 2013 15:59:25 PST
Received: by mail-ob0-f200.google.com with SMTP id un3so41729329obb.3 for <jose@ietf.org>; Wed, 20 Feb 2013 15:59:23 -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=SYcieUrCmV5lm/i3HMh/xHe4gUIbcN2vXmqXFblFtYI=; b=HfhByQ6xJphj3ar40M6LqlU+/3uU7Sn2LQyNyz1JXf2W9PztRa2iZ/HWz8+04v/1JW Cd79C6Zd7ZxQdi6k3+gmSwJDnGU/in1GYl+4vBaW+P18e1IdI9AplLNih3K2KDVpuwKh V49bIkaEQsnA64rBq9vGXrcjFjljqEgZx6/WeVpzqULDVByCFFCGC4pK1RL39cfFSHgj haSxtE8K63wpPVVsQlrHa3JfWVaPCpQ01Z1NJAqpPGu7aqiBG5Q+JYegLIpBHYcffFdQ W8NC6irlf/q8NFxPoYoEgGORWG9q6L0mWh9gU6w87KevWhCxrZvJ4DOhcp7E13mO0rIO hmTg==
X-Received: by 10.50.184.226 with SMTP id ex2mr12575933igc.24.1361404763636; Wed, 20 Feb 2013 15:59:23 -0800 (PST)
X-Received: by 10.50.184.226 with SMTP id ex2mr12575929igc.24.1361404763514; Wed, 20 Feb 2013 15:59:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Wed, 20 Feb 2013 15:58:53 -0800 (PST)
In-Reply-To: <CAL02cgShtAZssKzX_jiTroFczsepG=d=QaV_8=1kYoTk9UiHmg@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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 20 Feb 2013 16:58:53 -0700
Message-ID: <CA+k3eCQsratusrRNPv6hZG-mCsswx_sCKj=SqjfwP+vkAKxGZQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary=14dae9340dad5328e804d630bfbb
X-Gm-Message-State: ALoCoQnxbbFCDEy4JNoSUexuK06+oGCLk4N0EzA2AP4cm+1N4/w0roq215KSwPgnN3mgah2aEOblSLXiXWYROnbwHJ1bspskIc9Nz+ENS3hfrZE5+3vYvuM0mD1pE0HrfVl767O2UL9B
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: Wed, 20 Feb 2013 23:59:26 -0000

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
>>
>>
>