Hi Mike, On Tue, Apr 21, 2015 at 1:43 PM, Mike Jones <[email protected]> wrote:
> Jim, I assumed that her uses of JWT were typos for JWK. > Yep, thanks. > > > Kathleen, thanks for clarifying what you found confusing. I’ll think > about it some more, but my initial reaction is that the name “JWK > Thumbprint” is appropriate because it specifies a thumbprint computation > over a JWK representation of a key. Even if, per Section 3.4, the key > didn’t start life as a JWK, the thumbprint computation specified creates a > JWK representation of the key and hashes it. Hence “JWK Thumbprint”. I’ll > think some more, particularly when revising the introduction and > definitions, about how to make this clearer. > I'm fine with the term "JWK Thumbprint" if it is clearly defined and used consistently. It's just not clear to me that it is a "Key fingerprint" as well since required fields of the JWK are included in addition to the key. In that respect, it is more like a certificate fingerprint that includes the key and attributes of a certificate, but I understand it is a JWK Thumbprint. Thanks, Kathleen > > > Thanks again, > > -- Mike > > > > *From:* Jim Schaad [mailto:[email protected]] > *Sent:* Tuesday, April 21, 2015 10:37 AM > *To:* 'Kathleen Moriarty'; Mike Jones > *Cc:* [email protected] > *Subject:* RE: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04 > > > > Kathleen, > > > > Some of you message is confusing me. You keep referring to JWT in it. > Are you doing this as JW Token or JW Thumbprint? JWT is currently > “reserved” for the token and thus it is being confused. Can you clarify? > > > > Jim > > > > > > *From:* jose [mailto:[email protected] <[email protected]>] *On > Behalf Of *Kathleen Moriarty > *Sent:* Tuesday, April 21, 2015 8:48 AM > *To:* Mike Jones > *Cc:* [email protected] > *Subject:* Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04 > > > > Hi Mike, > > > > On Tue, Apr 21, 2015 at 11:22 AM, Mike Jones <[email protected]> > wrote: > > Hi Kathleen, > > > > Thanks for taking the time to review the draft and write up today’s and > yesterday’s comments. Replies inline below… > > > > *From:* jose [mailto:[email protected]] *On Behalf Of *Kathleen > Moriarty > *Sent:* Tuesday, April 21, 2015 7:47 AM > *To:* [email protected] > *Subject:* Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04 > > > > Another thing has been bugging me since reading the draft yesterday and > I'm not sure if this was discussed in the WG or not. There appear to be > differences in how a JWT thumbprint is described in the draft. I'd like to > see if we can work this out before progress the draft into IETF last call. > > > > The definition is not entirely clear. > > Section 3 clearly states that the required members of the JWT are part of > the thumbprint. > > Section 3.2.2, although the subtitle makes the point that this is about > why optional members are not included, the following sentence appears: > > The JWK Thumbprint value is a > > digest of the key value itself -- not of additional data that may > > also accompany the key. > > > > 3.2.2 was included in response to earlier review comments by Jim Schaad. > It’s there to motivate the particular choices made. Is there some way in > which you find 3 and 3.2.2 to be inconsistent? 3 is a positive statement > about what’s included and the sentence in 3.2.2 that you quoted above is a > negative statement about what’s not included, but that is consistent with > the positive statement. The negative statement is included to help readers > understand the reasoning. Is there some way in which you found it > confusing or misleading? Is there a particular change you might suggest to > alleviate your concern? > > [JLS] And I didn’t complain but it did not do a good job of what I asked > it to do. > > > > It is confusing. Is this a thumbprint of the JWT or just the key? If > it's just the key, it should be called a Key thumbprint. If it is of the > JWK members that includes a key, I'm fine with this being the "JWK > thumbprint". If it's just of the key, the quoted sentence above is fine, > but if the JWK required members are included and it's not just the key, you > have conflicting statements. > > > > > > Section 3.4 - Why is this allowed? If it's not in JWT format, it is some > other kind of thumbprint. You are essentially creating a JWK to have the > key and required members I am assuming, but that's not clear and this text > could leave interoperability challenges. > > > > 3.4 points out that the draft specifies a mathematical computation over a > key value, which can be performed on any key. It’s stating what’s > possible, more than what’s stating what’s allowed. Yes, you’re right that > you’d be creating a JWK representation of the key value to create the > thumbprint. If a thumbprint of the key is needed, this may be a reasonable > choice in some application contexts. > > > > Again, is this a "Key Thumbprint" or a "JWK Thumbprint". The draft needs > to be consistent and use the correct term depending on what type of > thumbprint this is. I'm assuming JWK Thumbprint, that is kind of similar > to a certificate thumbprint in that it's over a full set of data and not > just the key (JWK or certificate in the case of X.509). > > > > I hope that further clarifies why I find the text confusing. > > > > > > Thanks, > > Kathleen > > > > On Mon, Apr 20, 2015 at 3:23 PM, Kathleen Moriarty < > [email protected]> wrote: > > Hi, > > > > Thanks for your work on draft-ietf-jose-jwk-thumbprint-04. This is the > last one, right? Great job getting through the JOSE work! > > > > I read through the draft and have mostly editorial comments that I'd like > to see if we can fix. > > > > Section 2: > > The definition needs some tweaking: > > > > JWK Thumbprint > > The digest value for a key that is the subject of this > > specification. > > > > "the subject of this specification" should not part of text for a > definition. The definition needs to clearly explain the term without > having to read the whole specification. Can you suggest something else? > > > > Karen relayed text from Jim to me that I like and that will be used to > improve the definition. It was: > > > > “This document defines a method for computing a hash value over a JSON Web > Key structure. The document describes what the subset of fields in a key > to be used are, the method of creating a canonical form for those fields > and how to convert the resulting UNICODE string into a byte sequence > appropriate for hashing.” > > > > That helps to improve the abstract and introduction, thank you. How about > the definition of JWK Thumbprint? It should not include things like "this > specification" or "this document". It should be a stand alone definition. > > > > Section 4: > > > > Can you break this sentence into 2: > > However, if new JWK members are defined that use non-ASCII member > > names, their definitions should specify the exact Unicode code point > > sequences used to represent them, particularly in cases in which > > Unicode normalization could result in the transformation of one set > > of code points into another under any circumstances. > > > > OK > > > > Can you get rid of the parens around the second sentence? > > Use of escaped characters in JWKs for which JWK Thumbprints will be > > computed should be avoided. (Use of escaped characters in the hash > > input JWKs derived from these original JWKs is prohibited.) > > > > OK > > > > Can you reword this sentence/paragraph? I had to read it multiple times. > While I understand what you are saying, it could be easier to read. > > While there is a natural representation to use for numeric values > > that are integers, this specification does not attempt to define a > > standard representation for numbers that are not integers or that > > contain an exponent component. This is not expected to be a problem > > in practice, as the required members of JWK representations are not > > expected to use numbers that are not integers. > > > > OK > > > > General comment, the use of long sentences and frequency of parens make > the draft more difficult to read. > > > > Thanks for pointing this out. I’ll try to keep this in mind. > > > > Great, thanks! > > Kathleen > > > > Thanks! > > > > Thanks again! > > -- Mike > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > -- Best regards, Kathleen
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
