Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 16 January 2015 02:11 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB4C1A90AC; Thu, 15 Jan 2015 18:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWHqrks-47XJ; Thu, 15 Jan 2015 18:11:50 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80871A8F44; Thu, 15 Jan 2015 18:11:49 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id pv20so16736624lab.13; Thu, 15 Jan 2015 18:11:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jCI5pWfiGOeCp2PJKII8RsjjJ2agllNH44eTgq3u06E=; b=TDJeJusCpLsRg+GUsGt0vWCIvtfaNPtl5/de7cecYNqUdCuCzozEUT53QWeZ4M7mpX UjvfoTRqpnnIkEenMN1kMTMxDdn04p+Z9Mr6UN0FyKURbHc5NHMGxBAjqmQ6Rv+XhoYP ufXBNOQXvKvJGIFMoYQg89lJUafpG4Uso/c5Nv2wCgMcBZnri0Ik7mExTU68F1h/zM0F H9GuBs8Fdw7bg54jlWlIvfxL35pwP/LQdy88/R4RfcSCPnuEpZVc3JHkO+mGAD/EUIdf 1Gg9NXRVNqSDlNvjHaKfhusTHEndjDx2lOYUMBfZhnr8tQt9RWd4pTf9MqJYtWYrMeXA Cdyw==
MIME-Version: 1.0
X-Received: by 10.152.20.98 with SMTP id m2mr13163489lae.49.1421374308203; Thu, 15 Jan 2015 18:11:48 -0800 (PST)
Received: by 10.112.145.102 with HTTP; Thu, 15 Jan 2015 18:11:48 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB563FF@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB262D8@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgRzkXuJgUZ4LTHsiq8ou3zvQZRJFhvbn-Hkmc4BcftDXw@mail.gmail.com> <FED254BC-0616-416F-9624-870A4EA85767@gmail.com> <4E1F6AAD24975D4BA5B16804296739439BB563FF@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Thu, 15 Jan 2015 21:11:48 -0500
Message-ID: <CAHbuEH6ON0t_3emDA_VDt8zMF0XFFkS0mSYdmesQ_WuhDVjR5A@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/okHLxaXnVbkWSS-oR9iJZWIoLaM>
Cc: Richard Barnes <rlb@ipv.sx>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "draft-ietf-jose-json-web-key@tools.ietf.org" <draft-ietf-jose-json-web-key@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 16 Jan 2015 02:11:55 -0000

Richard,

I am close to be done with a final check on comments for this draft
and see that one of your comments was not addressed and maybe should
be.

The comment left in the datatracker is as follows:

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow
relying parties to verify the provenance of a key and binding of attributes to
it.

This is a slightly edited version from earlier discussions, which
leads me to think you may not have been happy with the 'discussion'
http://www.ietf.org/mail-archive/web/jose/current/msg04627.html

Can you take a look at this and if you have text to propose, that
would be appreciated.

On Tue, Nov 4, 2014 at 12:33 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> +1
>
>
>
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
> Sent: Monday, November 03, 2014 8:02 PM
> To: Richard Barnes
> Cc: Mike Jones; jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-key@tools.ietf.org; The IESG; jose@ietf.org
>
>
> Subject: Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>
>
>
> Thank you, Richard.
>
> Sent from my iPhone
>
>
> On Nov 3, 2014, at 10:14 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
> Thanks a lot!  I cleared.
>
>
>
> On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> Hi Richard,
>
> In -36 I added that if both "use" and "key_ops" are used, then the
> information they convey MUST be consistent, per your suggestion.  I also
> replaced the [TBD]@ietf.org with the actual list name.  Hopefully this will
> enable you to clear your DISCUSSes on this draft.
>
>                                 Thanks again,
>                                 -- Mike
>
> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Monday, October 20, 2014 9:19 AM
> To: Richard Barnes
> Cc: The IESG; jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org
>
> Subject: RE: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>
> Thanks for your responses, Richard.  Replies are inline below...
>
>> From: Richard Barnes [mailto:rlb@ipv.sx]
>> Sent: Saturday, October 18, 2014 11:38 AM
>> To: Mike Jones
>> Cc: The IESG; jose-chairs@tools.ietf.org;
>> draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org
>> Subject: Re: [jose] Richard Barnes' Discuss on
>> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>>
>> On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> Thanks for your review.  The -34 draft contains the following resolutions.
>> I hope that you can clear your DISCUSSes on that basis.
>>
>>                                 -- Mike
>>
>> > -----Original Message-----
>> > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard
>> > Barnes
>> > Sent: Wednesday, October 01, 2014 7:34 PM
>> > To: The IESG
>> > Cc: jose-chairs@tools.ietf.org;
>> > draft-ietf-jose-json-web-key@tools.ietf.org;
>> > jose@ietf.org
>> > Subject: [jose] Richard Barnes' Discuss on
>> > draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>> >
>> > Richard Barnes has entered the following ballot position for
>> > draft-ietf-jose-json-web-key-33: Discuss
>> >
>> > When responding, please keep the subject line intact and reply to
>> > all email addresses included in the To and CC lines. (Feel free to
>> > cut this introductory paragraph, however.)
>> >
>> >
>> > Please refer to
>> > http://www.ietf.org/iesg/statement/discuss-criteria.html
>> > for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
>> >
>> >
>> >
>> > --------------------------------------------------------------------
>> > --
>> > DISCUSS:
>> > --------------------------------------------------------------------
>> > --
>> >
>> > Section 4.3.
>> > "The "use" and "key_ops" JWK members SHOULD NOT be used together."
>> > Did the WG discuss how these could combine?  What was the outcome of
>> > that discussion?  This could be an important point for
>> > interoperability.  For example, WebCrypto enforces them both, so it
>> > will break if it gets a key with "use" and "key_ops" set to inconsistent
>> > values.
>> > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
>> > #rsa-
>> > pss-operations
>>
>> I believe that the working group discussion is accurately reflected in
>> this text from the spec:
>>    The "use" and "key_ops" JWK members SHOULD NOT be used together.
>>    Applications should specify which of these members they use, if
>>    either is to be used by the application.
>>
>> To keep things simple, applications should choose one or the other, based
>> on their needs.  Note that this is a "SHOULD NOT" - not a "MUST NOT", so if
>> WebCrypto believes they have a good reason to allow either or both, they're
>> not violating the spec.  But specifying which combinations are legal and
>> which aren't in the JWK spec seems very high on the complexity to usefulness
>> ratio.  I hope that you will choose to withdraw this DISCUSS on that basis.
>>
>> How about if we require that they be consistent if used together, but punt
>> the definition of consistency to WebCrypto?
>>
>> """
>>    The "use" and "key_ops" JWK members SHOULD NOT be used together.
>>    Applications should specify which of these members they use, if
>>    either is to be used by the application.  If both "use" and "key_ops"
>> members
>>    are present, then they MUST be consistent (see [WebCrypto]).
>> """
>
> I suspect some reviewers wouldn't agree with the "(see [WebCrypto])" part,
> but I can add the rest of your suggested sentence, if that will do it for
> you.
>
>> > Section 8.
>> > "[TBD]@ietf.org"
>> > This needs to be populated before approval.  I don't know what's
>> > customary here, but "jose@ietf.org" is an obvious candidate.
>>
>> Per the spec, jose-reg-review@ietf.org is already the recommended name.
>> Yes, we would create this list before final approval, just as
>> oauth-ext-review@ietf.org was created before RFC 6749 was approved.  I hope
>> that you'll choose to withdraw this DISCUSS on that basis.
>>
>> That sounds fine to me.  Who has the action to get that list set up?
>
> Kathleen is doing this, per earlier comments on the thread.
>
>> > --------------------------------------------------------------------
>> > --
>> > COMMENT:
>> > --------------------------------------------------------------------
>> > --
>> >
>> > Section 1.1.
>> > The pointer for BASE64URL should be to JWS.  One level of
>> > indirection, please :)
>>
>> Agreed
>>
>> > Section 4.
>> > It might be worth being explicit (here or elsewhere):
>> > "A JWK MUST NOT contain algorithm-specific members for key type
>> > other the one specified in its "kty" attribute."
>>
>> I agree with the sentiment, but this actually contradicts the statement
>> that member names that are not understood MUST be ignored.
>>
>> Good point.  Perhaps we could phrase this as a requirement on creators,
>> leaving consumers free to be more liberal?
>>
>> """
>> The creator of a JWK MUST NOT include algorithm-specific members for key
>> type other the one specified in its "kty" attribute.  Consumers of JWKs
>> SHOULD NOT reject JWKs with such members, however, in the interest of
>> extensibility.
>> """
>
> In another thread, Carsten Bormann had explicitly objected to situations in
> which there are different requirements on producers and consumers, unless
> absolutely necessary.  I don't think the situation you're describing (for
> instance, including an extraneous "x" value in an RSA key value) rises to
> the level of severity that it warrants placing different requirements on
> producers and consumers.  Rather, my intuition at this point (which could,
> of course, be wrong), is that doing so would be likely to itself generate
> DISCUSS positions.  I think we're better off leaving this as-is.
>
>> > Section 4.1.
>> > "cryptographic algorithm family used with the key"
>> > "... such as "RSA" or "EC"."
>>
>> Agreed
>>
>> > Section 4.7.
>> > "base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
>> > It seems unpleasant for implementations to have to support two
>> > flavors of base64, especially since this doesn't use PEM directly.
>> > Did the WG discuss just using BASE64URL?
>>
>> Not much, although each certificate value is actually a PEM-encoded value,
>> including allowing newlines, etc.  People agreed with that goal when we did
>> discuss it.
>>
>> > Section 9.1.
>> > It might help here to note that technologies like PKIX and JWT can
>> > allow relying parties to verify the provenance of a key and binding of
>> > attributes to it.
>>
>> Can you propose specific language for this?  What I have in mind is
>> delivering a JWK or JWK Set on a TLS channel using a URL that is
>> cryptographically bound to the use of the key - possibly using the URL as
>> the issuer of a JWT signed with the key, but you may have something else in
>> mind.
>>
>> I had in mind more the traditional, "use a certificate to bind attributes
>> to a key" sense.  How about this?
>>
>> """
>> In most applications today, there are trusted authorities that vouch for
>> the provenance of a key and bind attributes to it.  For example, in
>> PKIX-based applications, participants use certificates to verify that a
>> certificate authority has bound certain attributes to a key, such as a name
>> or key usage.  JWK supports this style of provenance through the "x5u",
>> "x5c", "x5t", and "x5t#S256" attributes, all of which reference a
>> certificate that a relying party can use to associate attributes to the JWK.
>> Other assertions systems, such as JWT, can likewise be used to assert
>> bindings of attributes to keys.
>> In some applications, it may also be convenient to use TLS as an ersatz
>> assertion mechanism.  For example, an application could require JWKs to be
>> downloaded with associated attributes over HTTPS as a way of having the
>> HTTPS server assert a binding of the JWK to its attributes.  This is similar
>> to the way that the XMPP POSH mechanism uses HTTPS to assert delegations
>> from one way to another.  In such applications, however, care needs to be
>> taken to ensure that secure transports are always used, and to avoid
>> confusion with other uses of the TLS server in question.  The former
>> situation would allow an attacker to create bogus assertions, and the latter
>> would let an attacker trick the server into issuing bogus assertions.
>> """
>
> It may be just me, but the whole notion of binding attributes to keys seems
> to be a bit off topic - at least in a section on "Key Provenance and Trust".
> The point of this section is that applications will make trust decisions
> about keys based on the trustworthiness of the way they got the key.
> Whether or not there may also be attributes bundled with the key is
> independent of this, so I'm not prone to talk about it here.  If you think
> it needs to be talked about elsewhere, can you motivate the reason for doing
> so?
>
> Other comments on your proposed text above follow...
>
> In what specific way are you thinking that "Other assertions systems, such
> as JWT, can likewise be used to assert bindings of attributes to keys"?
> While I agree that this is true, I suspect that most implementers wouldn't
> find that particular wording actionable.
>
> In your second proposed paragraph, while you're talking about "binding of
> the JWK to its attributes", I think the core of the message here is that TLS
> URLs can be used to provide clear provenance for sets of keys.  I'm fine
> with saying that in some way.
>
> I agree with your comments about secure transports being used and ensuring
> that keys are only retrieved from locations advertised by the application as
> being their key locations.
>
>>
>>                                 Thanks again,
>>                                 -- Mike
>
>                                 -- Mike
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose



-- 

Best regards,
Kathleen