Thanks a lot! I cleared. On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <[email protected]> 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:[email protected]] > Sent: Monday, October 20, 2014 9:19 AM > To: Richard Barnes > Cc: The IESG; [email protected]; > [email protected]; [email protected] > 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:[email protected]] > > Sent: Saturday, October 18, 2014 11:38 AM > > To: Mike Jones > > Cc: The IESG; [email protected]; > > [email protected]; [email protected] > > 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 <[email protected]> > 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:[email protected]] On Behalf Of Richard > > > Barnes > > > Sent: Wednesday, October 01, 2014 7:34 PM > > > To: The IESG > > > Cc: [email protected]; > > > [email protected]; > > > [email protected] > > > 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 "[email protected]" is an obvious candidate. > > > > Per the spec, [email protected] is already the recommended > name. Yes, we would create this list before final approval, just as > [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/jose
