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

Richard Barnes <rlb@ipv.sx> Tue, 04 November 2014 03:15 UTC

Return-Path: <rlb@ipv.sx>
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 F0C9E1A8891 for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 FI-23XxEFx5m for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:14:57 -0800 (PST)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8992A1A8887 for <jose@ietf.org>; Mon, 3 Nov 2014 19:14:57 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id hy10so6258442vcb.40 for <jose@ietf.org>; Mon, 03 Nov 2014 19:14:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3HjdpqVf/UsH3QJRHwB3GTE794AWIWn+nlmfU7TsYx8=; b=BJ6OmXLJPrXVndjFD5UmC0dUgkllnrCEuouzbhZyqP0dBaLmOO3Bv+G4ftAFBn5JDv 6QD52eiKep+pmVPjSrBM9Pi0x3bgJkY+y9f8mfzY7FfzmBEbgWNHLY5JXiJtxHT0kSb5 WMPdAm+6QUroiqwmCR+7lLpSpEL6YOLNPuHMnBNYXlZLPcI5AR84Q0j4JSefrxeIvOVB 8A+cMegioZiyXCxbOmC/UNtmfjUxy+VoRlVZsPFCoPgFJySnkRfoqY059skmNyQjW3cH JTt2YzNERQbaZ2MAxb7RMmq5rwbmoKH3rMthh3jaVeALs1xWvlqalU4r2vfoFp8XjGYU ZWZg==
X-Gm-Message-State: ALoCoQmdp4Yw6I78KAFSA1qDzjZGk/YMRbdVeLgbsWSmFEUDiCTq9EWTJPai5lvO3kqvKGCykwcZ
MIME-Version: 1.0
X-Received: by 10.221.19.1 with SMTP id qi1mr35434322vcb.24.1415070896661; Mon, 03 Nov 2014 19:14:56 -0800 (PST)
Received: by 10.31.149.205 with HTTP; Mon, 3 Nov 2014 19:14:56 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB262D8@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB262D8@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Mon, 3 Nov 2014 22:14:56 -0500
Message-ID: <CAL02cgRzkXuJgUZ4LTHsiq8ou3zvQZRJFhvbn-Hkmc4BcftDXw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a1133a02820bd230506ffded0
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/rRXnUVyGghoLJxUupn0nwcobnLA
Cc: "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: Tue, 04 Nov 2014 03:15:02 -0000

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