Thank you, Richard. Sent from my iPhone
> On Nov 3, 2014, at 10:14 PM, Richard Barnes <[email protected]> wrote: > > 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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
