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

Richard Barnes <rlb@ipv.sx> Fri, 16 January 2015 02:35 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 206CB1A90D0 for <jose@ietfa.amsl.com>; Thu, 15 Jan 2015 18:35:58 -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=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 u2QLObBAdvXp for <jose@ietfa.amsl.com>; Thu, 15 Jan 2015 18:35:53 -0800 (PST)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB531A90CC for <jose@ietf.org>; Thu, 15 Jan 2015 18:35:52 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id pv20so16798264lab.13 for <jose@ietf.org>; Thu, 15 Jan 2015 18:35:50 -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=8v0edT0KzmTUAY54Mxizl7HazwhmIa0Q+/t16+LvcDg=; b=AwLUQJCMk6aQJB8y0tBH1jupL2jXGKe+GQDxRFYW4EV9lfO+anBCc1wKy6JlLadx3j GYuKpNUKeFNphSyLT35P5izIw94zPUuxS4dGUdSFhokPHcfuJV7S4ED4nBa/b+SCApHW 6lO3BGCFqhQP4jLT2BXSsqxPbiRtvnEgvd33XwfvIhy9qlLbYL9eVoGNE6CUgs22HbKs GWAtY/1cwa8WwhysoSsMR1BmYqNPJ2aNI/8/mMPaMntbafrA31szub03CUW++JXERZga oLVIv6Kdx824u+lGDjBi/yFINNaXlTzyd0wUEaIctexE6f+NG3FQdP2GFRg/oEWfNWMC yeCQ==
X-Gm-Message-State: ALoCoQk5aOSHAyUKVxjFut+Xo4fvcWmq3cM/nUVLvjaLm3s86+I2CQY126ynOSpV21hHPGtsF86k
MIME-Version: 1.0
X-Received: by 10.112.25.7 with SMTP id y7mr13042123lbf.94.1421375750600; Thu, 15 Jan 2015 18:35:50 -0800 (PST)
Received: by 10.25.12.215 with HTTP; Thu, 15 Jan 2015 18:35:50 -0800 (PST)
In-Reply-To: <CAHbuEH6ON0t_3emDA_VDt8zMF0XFFkS0mSYdmesQ_WuhDVjR5A@mail.gmail.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> <CAHbuEH6ON0t_3emDA_VDt8zMF0XFFkS0mSYdmesQ_WuhDVjR5A@mail.gmail.com>
Date: Thu, 15 Jan 2015 21:35:50 -0500
Message-ID: <CAL02cgTW9vDRovf4RVqfxj4CHZmxcR5R2rvT4QDzJ8eCer5nYQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c3f1a6b50e5e050cbbd497"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/vctTDjKtLrk2CMFe30hHwq6H7nM>
Cc: Mike Jones <Michael.Jones@microsoft.com>, "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:35:58 -0000

On Thu, Jan 15, 2015 at 9:11 PM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

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

Chatted this over with Mike briefly, think the following captures our
intent better.  (Obviously, Mike should feel free to object/revise/etc.)

"""
In almost all cases, applications make decisions about whether to  trust a
key based on attributes bound to the key, such as names or  roles, rather
than the raw key itself.  When a relying party is  trying to decide whether
to trust a key, there are several ways that he  can associate attributes to
the JWK.  Two examples that are relevant to JWK are PKIX and JWT.

The  creator of a JWK can include a PKIX certificate in the JWK's "x5c"
attribute.  If the relying party verifies the certificate, and verifies
that the JWK corresponds to the subject public key in the certificate,
then the JWK can be associated with the attributes in the certificate, such
as the subject name, subject alternative names, extended key usages, and
its trust chain.

JSON Web Token (JWT) objects can associate attributes to a JWK by
referencing the JWK  as a claim in the JWT.  The JWK can be included
directly as a claim value, or the JWT can include a secure reference to the
JWK (e.g., an HTTPS URI).  Either way, a relying party that gets a JWK from
a JWT claim can associate it with the JWT's cryptographic properties and
optionally the additional claims in deciding whether to trust the JWK.
"""




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