The holiday season derailed progress a bit but we are working to get back on track. That PR has now been merged. We hope/expect to have that and a few other items in a -15 draft published next week.
On Fri, Dec 20, 2024 at 5:17 AM Deb Cooley <debcool...@gmail.com> wrote: > - 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.* > > -- _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
