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 16:57 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 411EF1ACEEF for <jose@ietfa.amsl.com>; Fri, 16 Jan 2015 08:57:24 -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 27ZtcbZmSDZf for <jose@ietfa.amsl.com>; Fri, 16 Jan 2015 08:57:17 -0800 (PST)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F252F1ACE44 for <jose@ietf.org>; Fri, 16 Jan 2015 08:57:16 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id u14so19422792lbd.9 for <jose@ietf.org>; Fri, 16 Jan 2015 08:57:15 -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=BBYAbxKlHutow5gektBnNE78vzs7CeuqywJps7Bn3Kg=; b=TDYzbGHJXJ9idMvQOh/+SCDU2XKh7h/sDKWqHHnb/UWTyIVdOrSD1vTaF7fiis38YC bZVdXfaN5BhbI8nWomMMAUu+Aitviii4zMmb3eDG35YsyXL7nIVvk31tvR69Pb7Zs/rO BH4HGmUMK9lC9wrJRi+R/BK5b5gT+hlExKUU9OJ5y+CyDAPQu3jZ2mtJTWzxWj+QljQy c3jOF/mQ+9SSC7BB+NxlKXgSjG1hlb05YbjILeBdZoP0L28AW6joJrsedNJvC0dOZBzb 5XmRcby3Porkfcqp+Vjfnl4S+jzmu08bU5DMmjV1MEOswc8n/s04X38SvtNS9ksApQ7x 8xKw==
X-Gm-Message-State: ALoCoQldJO4WAEpwWy2b2z1WcGCIBU5vG6IxqGEvLk+kU7CVI5PN9mFd4ocHyTLrefGnQR03cTUf
MIME-Version: 1.0
X-Received: by 10.112.85.11 with SMTP id d11mr16707979lbz.100.1421427435418; Fri, 16 Jan 2015 08:57:15 -0800 (PST)
Received: by 10.25.12.215 with HTTP; Fri, 16 Jan 2015 08:57:15 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439E6525AA@TK5EX14MBXC291.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> <CAHbuEH6ON0t_3emDA_VDt8zMF0XFFkS0mSYdmesQ_WuhDVjR5A@mail.gmail.com> <CAL02cgTW9vDRovf4RVqfxj4CHZmxcR5R2rvT4QDzJ8eCer5nYQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439E6525AA@TK5EX14MBXC291.redmond.corp.microsoft.com>
Date: Fri, 16 Jan 2015 11:57:15 -0500
Message-ID: <CAL02cgTqxtdJHo0reJHZxh0P90DOZa_2B1R+k41XnpSfm=hsCg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11345ed65ccd3c050cc7ddcc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/vaEQyouDypq8I9fBA7qFazTS-OM>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.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 16:57:24 -0000

That text looks fine to me!

On Thu, Jan 15, 2015 at 10:02 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  How about this (slightly revised) wording?
>
>
>
> In almost all cases, applications make decisions about whether to trust a
> key based on attributes bound to the key, such as names, roles, or the
> source of the key, rather than based on the key itself.  When an
> application is deciding whether to trust a key, there are several ways that
> it can bind attributes to a JWK.  Two example mechanisms are PKIX [RFC5280]
> and JSON Web Token (JWT) [JWT].
>
>
>
> For instance, the creator of a JWK can include a PKIX certificate in the
> JWK's "x5c" member.  If the application validates 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.
>
>
>
> Also for instance, a JWT can be used to associate attributes with 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 TLS-secured URI from
> which to retrieve the JWK value.  Either way, an application that gets a
> JWK via a JWT claim can associate it with the JWT’s cryptographic
> properties and use these and possibly additional claims in deciding whether
> to trust the key.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Richard Barnes [mailto:rlb@ipv.sx]
> *Sent:* Thursday, January 15, 2015 6:36 PM
> *To:* Kathleen Moriarty
>
> *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)
>
>
>
>
>
>
>
> 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
>
>
>