- Paul.... Brian,
I have checked the github PR and it appears to cover all my 'to do' items (marked with a '*') in the previous message. Thank you for this. Deb On Thu, Dec 12, 2024 at 11:23 AM Brian Campbell <bcampb...@pingidentity.com> wrote: > Thanks for the detailed review and treatment of the issues Deb, > > The document editors will take an action to incorporate the indicated > changes in the next draft. > > On Thu, Dec 12, 2024 at 6:58 AM Deb Cooley <debcool...@gmail.com> wrote: > >> +oauth working group and Paul: >> >> Denis, >> >> I have gone through every issue request you have made on this draft. I >> would like to know what your motivation is for these drafts (I see you have >> done the same on the SD-JWT-VC draft). It sort of looks like comment >> spam. I realize that you are a long-time participant in the IETF, and >> you obviously have your ‘style’. Once I understand your motivation, >> then we can work towards that goal. >> >> I will also say that if a particular draft doesn’t suit your needs, then >> it is always possible for you to author a draft and support it through the >> process. >> >> Below are both my general comments, and then blow by blow responses to >> your 42 issues. >> >> Deb Cooley >> >> ------------------------------------------- >> >> My general comments on the issues: >> >> 1. End-User comments: These are implementation choices. Holder is >> basically the front for all sorts of different implementation options. Any >> implementation can be constructed to be secure, or insecure. The format >> (this draft) doesn’t control that. There are many comments that are >> focused on the End-User vs Holder discussion. See Daniel’s explanation >> here: >> https://mailarchive.ietf.org/arch/msg/oauth/o_GsCqflyoA-Kd4ZCg5QlYy_tdQ/ >> . >> >> >> >> 2. Comments on Introductory material: In my opinion, the >> introduction needs to be clear, concise, and straightforward. Adding >> complexity doesn’t help ‘set the stage’ for the detail part of the draft. >> There are many comments on the Intro text. >> >> >> >> 3. Organization of the draft: Choices are made by authors about >> where to put the detail. If that detail does in fact exist already in >> the draft, comments asking for it to be repeated or moved MUST have good >> rationale. There are several comments like this. >> >> >> >> 4. Editorial comments: I agree these should be easy to fix, but if >> one insists on burying the lead, i.e. putting the editorial comments in the >> midst of other comments, then they are easy to miss. I have put ‘*’ by >> the editorial comments I want the authors to fix. >> >> >> >> 5. Age examples: This points to ongoing work in this area. Martin >> Thomson has a blog: https://lowentropy.net/posts/selective-disclosure/ . >> Salted hash-based selective disclosure might not be the perfect answer >> for this particular use case. But it is fine for other use cases. My >> comment here is to not let perfect be the enemy of good. >> >> >> >> 6. Security Considerations: I am going to ask for some additions >> here. Not that the draft needs to address these items, just to make >> clear that they must be done correctly and are out of scope for this >> particular draft. >> >> >> >> 7. PQ algorithms: This draft does not address algorithms at all, >> they point to JOSE where the algorithms will be specified. There could >> be a note in the Security Considerations section, if the authors so desire. >> >> ------------------------------------- >> >> Line numbers that I reference are from idnits. The list of issues is >> below with my comments: >> >> - #498 Figure 1 should be corrected to take into account the >> existence of an End-user and to consider KB-JWT instead of KB >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/498> >> >> *Lines 268-297: The addition of the End-User implies implementation. WRT >> the holder to Verifiers text, I would suggest ‘Presents SD-JWT or SD-JWT+KB >> including selected Disclosures’ to account for the KB-JWT. >> >> - #497 The term End-User should be added to the definitions >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/497> >> >> Lines 220-266: Given the term ‘end-user’ does not occur within the draft, >> I disagree. >> >> - #496 The definition of a Verifier would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/496> >> >> Lines 265-266: I thought providing all disclosures was an option? The >> current definition is clearer and more complete. >> >> - #495 The definition of an Holder would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/495> >> >> Lines 261-264: The suggestion is pertinent for one possible >> implementation of the format. Keeping the format language clear and >> concise is important. >> >> - #494 The definition of an Issuer would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/494> >> >> Line 260: This seems superfluous, again language needs to be clear and >> concise. >> >> - #493 The definition of a "key binding JWT" would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/493> >> >> *Lines 253-256: I would reorder the sentences in the definition where the >> last sentence is ‘The details of how a JWT for proving Key Binding is >> defined in Section 4.3.’ (putting the second sentence first). Certainly, >> details and requirements of how this is done is not suitable for a >> terminology section. >> >> - #492 The definition of "key binding" would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/492> >> >> *Lines 248-252: I agree that ‘legitimate possession’ isn’t quite right >> (nor provable). I suggest removing the word ‘legitimate’. As for >> implications that the construction of the system w/ one or more end-users >> that utilize a single holder is out of scope. This draft is merely the >> format, not the implementation. >> >> - #491 The definition of the Selectively Disclosable JWT (SD-JWT) >> would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/491> >> >> Lines 237-241: ‘zero or more’ includes ‘all’. It makes it very >> difficult to implement if requirements are buried in terminology sections. >> No changes required. >> >> - #490 The definition of the SD-JWT+KB structure needs to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/490> >> >> Line 217-218: Still Introduction. The details of how the format works >> is in Section 4.3. >> >> - #489 A (KB-JWT) does not demonstrate a "proof of possession" of >> private key >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/489> >> >> *Line 215: Still Introduction, the authors could add the word ‘allow’, >> since a format itself does not prove possession of the private key. >> >> - #485 Key binding will be ineffective unless the SD-JWT includes an >> additional claim that indicates the Holder characteristics: "hcahr" >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/485> >> >> Lines 182-190: Introduction text needs to be clear and concise. Details >> of how the format/mechanism is designed are in Section 4.3. In >> addition, this feature appears to me to be very much like a certificate >> validate used in TLS to prove the server (or client) is in possession of >> the private key. >> >> I would disagree with your first statement (that is exactly what key >> binding is for). >> >> One can quibble about whether use of a private key equates to possession, >> but that is not useful in an introduction. >> >> The holder must prove it possesses the private key to the issuer, and >> then to the verifier when the claim is presented. >> >> None of this text belongs in an introduction. >> >> - #488 What is a "facility for associating an SD-JWT with a key pair" >> ? >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/488> >> >> *Line 214: I don’t think ‘facility’ here means ‘a physical place’. I do >> think the Authors could pick a better word. Maybe ‘ability’? >> >> - #487 Difference between "a format extending the JWS Compact >> Serialization" and "an alternate format extending the JWS JSON >> Serialization" ? >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/487> >> >> Lines 203-208: It is unclear to me what is unclear here. Section 8 >> describes the alternate format. The rest of the draft describes the >> primary format. Section 1.1 is still Introduction. >> >> - #486 The structure called "SD-JWT+KB" should be renamed >> "SD-JWT+KB-JWT" >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/486> >> >> Assuming lines 189-190: There is no loss of clarity as it is currently >> stated. >> >> - #484 A Holder does not present a "JWT" to a Verifier but "SD-JWT + >> Sel.Claims" >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/484> >> >> Assuming lines 159-161: Again, this is still the Introduction. Using >> consistent wording is going to be easier for a developer to understand. >> Introducing >> terms like ‘talking to’ is confusing. If the Holder is the End-User >> does that actually speak to the verifier? >> >> - #483 Indicate that "claims" refers either to object properties >> (name/value pairs) and to array elements >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/483> >> >> It is unclear to me which part of the Introduction this comment is >> referencing, but the supplied text makes the Introduction more complex. The >> details of what a claim can consist of should be in the body of the draft, >> not the Introduction. >> >> - #482 Make a difference between the Holder which is an *application* >> and the individual (i.e. End-User) >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/482> >> >> Assuming you are referring to lines 156-158, this is made clear in the >> terminology section definition of Holder. >> >> - #522 The last paragraph of section 10.5 (Issuer Identifier) can be >> removed >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/522> >> >> Given my comment on the previous issue (#521), this one is OBE. >> >> - #521 A new section about "Issuer anonymity" should be added >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/521> >> >> The current Section 10.5 gives a mitigation. Some entity has to be >> accountable. It is extremely difficult to hold an anonymous entity >> accountable. >> >> - #520 Section 10.3 (Confidentiality during Transport) should also >> mention integrity >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/520> >> >> The SD-JWT itself is signed, which handles the integrity requirement. In >> addition, modern TLS implementations provide Confidentiality and Integrity >> by default. >> >> - #519 Since claims always contain privacy-sensitive data section >> 10.2 would need to be reworded >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/519> >> >> Since this is a ‘SHOULD NOT’, it leaves the option for other actions. >> >> - #518 Holders SHOULD NOT be required to store SD-JWTs "only in >> encrypted form" >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/518> >> >> The statement is a SHOULD, it leaves the option for other protection as >> an option. >> >> - #517 Section 10.2 should be made more general to consider both the >> storage of signed and un-signed data >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/517> >> >> It is appropriate for this draft to handle SD-JWT data. It is >> completely obvious that unsigned sensitive data should be protected. No >> need for that to be specified here. >> >> - #515 The term "unlinkability" is overloaded. For more clarity, the >> wording "End-user intrackability" should be used in addition >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/515> >> >> No action. Making up new terms here isn’t terribly useful. >> >> - #516 A new section about "End-User intrackability" should be added >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/516> >> >> How end-users interact with Holders (and every other part of this) is an >> implementation detail. SD-JWT is merely the format. >> >> - #514 A section should be added to consider the case of a >> presentation of claims to Verifier that have been issued by different >> Issuers >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/514> >> >> This looks like an implementation decision to me. The SD-JWT draft >> specifies the format, how it is used is determined by the implementation. >> >> - #513 Section 9.5 (Key Binding) needs to be revised to consider the >> case of a collusion between End-Users >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/513> >> >> *This is an implementation issue. Only one point do I agree with – >> ‘legitimate’ is not provable. It should merely be removed from the >> section. >> >> - #512 Section 7.3 needs to be revised to describe which data >> structures can be transmitted >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/512> >> >> Section 7.3: As this section stands, the terminology is correct. >> >> - #507 It is important to mention the use of decoy digests and of the >> shuffling of the digests included in the SD-JWT payload >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/507> >> >> Section 4.2.1 and 4.2.2: It is unclear why one would include this text >> before Section 4.2.5, where decoy digests are discussed. In addition, >> this guidance appears to be better applied to a specific implementation. >> >> - #511 The requirement for an Issuer of not providing a SD-JWT+KB-JWT >> should be removed >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/511> >> >> Lines 1521-1522: It is up to an implementation to determine where the key >> binding key pair is generated. In the case that the Issuer issues it, >> then it is wise for the Holder to verify that it has received just the >> SD-JWT (in this case, the private/public key pair has to be transmitted to >> the holder, but that is out of scope for this draft). In the case that >> the Holder, or other entity generates the key pair, then it is less likely >> that the Issuer could construct the KB-JWT. It is still a trivial check >> and worth doing for completeness. >> >> - #510 Verification steps for the KB-JWT are missing in section 7.1 >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/510> >> >> Section 7.1: Right, they are in Section 7.3 (as stated in Section 4.3). >> >> - #509 Validation steps for the KB-JWT are missing >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/509> >> >> Lines 880-893: As stated in the section, the verification steps and >> details are located in Section 7.3. >> >> - #508 The iat time at which the Key Binding JWT was issued should >> not be REQUIRED >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/508> >> >> Lines 850-852: I disagree. Depending on how long a nonce is kept by the >> system that generates it, the time that the KB JWT was issued allows >> another option to prevent replay. >> >> - #506 How the Holder key pair is established cannot be placed "out >> of the scope of this document" >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/506> >> >> *Lines 534-538: I believe this is Section 4.1.2: Better to list this as >> ‘out of scope’ than to do a half way job of laying out the requirements. >> Note: the replacement text has nothing close to the list of >> requirements that would need to be levied to ensure secure key pair >> generation, let alone how those key pairs are handled, stored, and >> maintained from birth to death. Again, this is a format, not an >> implementation. This should be added to security considerations (if it >> is not already there). >> >> - #505 Add an example of using arrays for "age_over" and "age_under" >> claims >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/505> >> >> Section 4.2.2: The appendices are a better place for these. I believe >> there are some examples there already. >> >> - #504 It would be worth to mention that the Issuer decides which >> claims are always disclosed >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/504> >> >> Lines 489-490: This comment makes the text repetitive (either by the >> numbered list above this or that para after. >> >> - #503 The description of the SD-JWT+KB is confusing >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/503> >> >> Lines 380-382: Note: this comment was addressed in Github >> >> - #502 The description of the SD-JWT can be improved >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/502> >> >> Lines 375-376: Is the issue whether zero Disclosures is appropriate? If >> so, why? The comment doesn’t state a reason. >> >> - #501 The benefits of the nonce and of the audience value can be >> made more accurate >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/501> >> >> Lines 348-350: Where the nonce comes from is an implementation detail (it >> is listed as out of scope in Section 4.3). Draft 14 has ‘verifier’ in >> place of ‘audience’ already. >> >> - #500 The data elements sent to the Verifier are not correctly >> defined >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/500> >> >> Lines 327-331: Note there is only one para, and one sentence. It is >> unclear where the commenter wants the change made. [The addition of >> end-user implies implementation.] >> >> - #499 The format used to carry both the SD-JWT and the Disclosures >> is unclear >> <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/499> >> >> *Lines 318-320: This can be easily clarified by changing ‘Holder as >> part of the SD-JWT’ to ‘Holder with the SD-JWT’ >> >> · #529 43. Update of Issue #514 (new section 9.12) for the >> support of Post Quantum cryptography #529 >> >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/529 >> >> This draft does not specify the selection of the algorithm used for >> signing either SD-JWT or SD-JWT-KB. It does point to “digital signature >> algorithm identifier” such as per IANA JSON Web Signature and Encryption >> Algorithms registry, and it does specify that it MUST NOT be ‘NONE’. When >> the JOSE working group specifies post quantum signature algorithms, then >> they will be available to be used to sign SD-JWT. >> >> >> >> On Wed, Nov 27, 2024 at 1:56 PM Denis <denis.i...@free.fr> wrote: >> >>> Dear Security Area Director, >>> >>> Please consider this email as a Formal appeal acc. Section 6.5 of IETF >>> Directives on Internet Standards Process (RFC 2026). >>> A person who disagrees with a Working Group recommendation shall >>> always first discuss the matter with the Working Group’s chair(s), >>> who may involve other members of the Working Group (or the Working >>> Group as a whole) in the discussion. >>> >>> I discussed the matter with the Working Group’s chair(s) and since my >>> concerns have not been addressed to my satisfaction >>> by the co-chairs, I am making a Formal appeal to you in your quality of >>> IETF SEC Area Director. >>> >>> As you will see below, I have reviewed in detail >>> draft-ietf-oauth-selective-disclosure-jwt-14. >>> >>> During the first WGLC, my comments have been ignored and ignored, once >>> again, during the second WGLC. >>> >>> During the second WGLC, I raised 41 issues on github and they have been >>> promptly closed by one of the co-editors >>> to prevent discussions. >>> >>> I don't believe that it is a fair process. I am a former co-editor of >>> several RFCs (my first one was RFC 3161) >>> and when I was in this position I used to address and respond to all the >>> comments made by the WG participants. >>> >>> I am involved in ISO JTC 1 SC 27 (Information security, cybersecurity >>> and privacy protection) and I do know that the process is different, >>> In ISO JTC 1, when a comment is made after a call for comments, a >>> proposed Doc (Disposition of Comments) is prepared and then >>> discussed during a meeting. All the comments need to be answered and, >>> for each comment that is not accepted, a rational must be given. >>> >>> Some of the issues I raised are editorials. They have not even been >>> considered. Many other issues are major. >>> My most important concerns are indicated at the very end of this email >>> and, for your convenience, are copied below: >>> >>> 1) The format of the SD-JWT that is currently described in -14 is >>> INSECURE >>> as it is unable to counter End-Users collaborative attacks. >>> This type of attack is ignored in the "Security Considerations" >>> section and thus is not considered / addressed within the document. >>> Collusion attacks exist both for Verifiers and End-Users. This >>> topic relates to issue #485. >>> >>> 2) The key management protocol that is currently described in -14 DOES >>> NOT support the "Verifier-Verifier unlinkability" property. >>> >>> 3) The cryptographic algorithm which is currently used by the Holder >>> and is described in -14 is NOT Post-Quantum resistant, >>> whereas it can be made Post-Quantum resistant. This is >>> important in the context of algorithm agility. >>> >>> Since this draft is already mentioned in the ARF (version 1.4.1) of the >>> EUDI wallet, its content will be rather important. >>> >>> If draft-ietf-oauth-selective-disclosure-jwt were adopted "as it is", >>> this would be a protocol that would allow Verifiers >>> to link their user accounts (which is a privacy concern) and would not >>> allow Verifiers to detect users collaborative attacks >>> (which is a security concern). >>> >>> FYI, none of the OAuth virtual meetings scheduled by the co-chairs in >>> the next months will be dedicated >>> to draft-ietf-oauth-selective-disclosure-jwt. >>> Best regards, >>> >>> Denis PINKAS >>> >>> President of DP Security Consulting SAS (France) >>> >>> PS. Please, would you acknowledge the receipt of this email ? >>> >> >> snip.... >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
