Thanks Deb, Just one quick clarification - those changes are not yet published as a draft but rather 'staged' in git[hub]. A new draft will be out soonish though.
On Wed, Apr 30, 2025 at 10:57 AM Deb Cooley <debcool...@gmail.com> wrote: > Denis, > > I have the following responses inline marked as [DC] in the summary only > (to save pages and pages of reading) > > I have asked for two changes, which the authors have already published in a > new draft. There is one issue/change that is in progress. > > Note: I still do not see where the typo occurs in this (very long) message > chain. > > Deb Cooley > Sec AD > > On Mon, Apr 14, 2025 at 1:21 PM Denis <denis.i...@free.fr> wrote: > > > The IESG has received a request from the Web Authorization Protocol WG > > (oauth) to consider the following document: - 'Selective Disclosure for > JWTs > > (SD-JWT)' > > <draft-ietf-oauth-selective-disclosure-jwt-17.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to > thelast-c...@ietf.org mailing lists by 2025-04-14. Exceptionally, > comments may > > be sent to i...@ietf.org instead. In either case, please retain the > beginning > > of the Subject line to allow automated sorting. > > > > > > > > > > > > > > > > > > > > > > > > > > *The following comments are posted exceptionally to i...@ietf.org > > <i...@ietf.org>, because previously I responded to the first and second > WG > > LC and I got no reply to my comments. After the second WG LC, I have > posted > > on github https://github.com/oauth-wg/oauth-selective-disclosure-jwt > > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt> 40 issues > > numbered #482 until #522 that have not been responded. Then after 16 > > comments: #546 to #562, that have not been responded either. Hence, many > > of the comments that are posted today are not new comments. I believe > that > > some of them are substantive. I made a full review of the document (with > > the exception of the appendices) and I will first present my 17 comments > > shortly. A. As currently described, the protocol is insecure as it can be > > subject to security attacks that have not been identified. * > > > > * The draft considers "colluding Verifiers and Issuers" but omits to > > consider "colluding Holders and users" which can also exist. * > > > > [DC] Not a new comment: Last time around I called this an implementation > issue (holders w/ hardware key stores and such). Most of the key > handling/storage/protection parts are covered in Section 9.12 which states > that keys have to be protected across the lifecycle. No change required. > > > > > > * A detailed example of such an attack is provided. Key binding does not > > provide a proof of *possession* of a private key (PoP) but only a proof > of > > *use* of a private key (PoU). The difference is quite important. Detailed > > explanations are provided. * > > > > [DC] Not a new comment. This is editorial at best. Use of a private key > via signed message is a classic way of proving possession of that key for > the last 35 years at least. Certainly, the entity that performs the > signature possesses the key. No change required. > > > * See comments 1, 2, 3, 4 and 5 under the topic **COLLUDING HOLDERS AND > > USERS** and **under the topic* *KEY BINDING**.* > > > > > > *B. As currently described, there is insufficient guidance in the draft > > that allows to correctly implement a **Key Binding JWT* > > > > * replay detection mechanism. In general, two methods can be used, but > the > > draft does not allow to know which one has been selected by the Holder. > The > > processing by the Holder and by Verifier is insufficiently explained. See > > comment 6 under the topic of REPLAY DETECTION OF a **Key Binding JWT* > > *.* > > > > [DC] Not a new comment: In fact, Section 7.3 #6 lays out the components to > detect replay. To clarify, your position has shifted from not requiring > iat to replacing the nonce with two separate fields (rdn and chal). > *For the authors: Section 7.3, #6: protection/detection. > > > > * C. **SD-JWT SUSPENSION OR REVOCATION IS MISSING* > > * (See comment 7)* > > > > *[DC] For the authors: The very first bullet of Section 7.1 states: “the > Issuer-signed JWT is valid, i.e., it is signed by the Issuer and the > signature is valid,..” Change to: “the Issuer-signed JWT is valid, i.e., > it is signed by the Issuer, the signature is valid, and it is not suspended > or revoked,…” > > > > * D. **UNLINKABILITY** It is important to introduce the term > "one**-time-use > > digital **credential" (See **comment 8)* > > *.* > > > > [DC] as written now, a Holder can use a credential once. No change > required. > > > > > > > > *E. POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS * > > > > * I propose to add a new section that explains how one-time-use digital > > credentials that include a public binding key * > > *can support Post-Quantum resistant key binding algorithms. Even if the > > document does not mandate the use of * > > *any specific asymmetrical algorithm, this information can be useful for > > implementers **as it is not widely shared* > > *. **(See **comment 9).* > > > > [DC] This is not a new comment. This response is also not new: 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. > > > > > > * F. VOCABULARY * > > > > *Since Figure 1 does not describe the interactions between the Holder > > software and hardware and a human user* > > *a Holder can only be the **"software and hardware" (**See **comment > 10).* > > > > [DC] Again, not a new comment: The suggestion is pertinent for one > possible implementation of the format. Keeping the format language clear > and concise is important. > > > > > > * G. ARRAY ELEMENTS. Various comments (See comments 11 and 12).* > > > > > *[DC] 11. A potential for a slight change, in progress… > [DC] 12. multiple nationalities are already mentioned/described in Section > 4.2.6. No change required. > > > > > > > * H. KEY PAIR GENERATION AND LIFECYCLE MANAGEMENT (See a minor comment > > 13).* > > > [DC] there is no mention of honest and dishonest owners in NIST SP 800-57 > part 1, r5. How exactly does this lead to a false sense of security? No > changes required. > > > > > > > * I. EDITORIAL COMMENTS (See comments 14 to 17).* > > > [DC] none of these require changes. Either they are clear already, the > editor will correct grammar, colluding Verifiers are indeed adversaries, > and integrity is already provided why is extra integrity protection > required. > > > > > > > > * ============================================================ > **COLLUDING > > HOLDERS AND USERS* > > > > * 1. * > > *Collaborative attacks between colluding users and Holders * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Page 12 states: It is out of the scope of this document to describe > > how the Holder key pair is established. For example, the Holder MAY > > create a key pair and provide a public key to the Issuer, the Issuer > MAY > > create the key pair for the Holder, or Holder and Issuer MAY use pre- > > established key material. The document does not also consider how the > > protection of the *use* of the key pair should be done. Whether this > > protection is "good", "weak" or inexistent has a great importance. As a > > simple example, if the key pair can be exported from a Holder and then > > imported into another Holder, then that other Holder will be able to use > > the private key and get advantage of SD-JWTs that were under the control > of > > the first Holder. A more elaborated example is the ability for a Holder > to > > perform all the cryptographic computations that are necessary for another > > Holder without releasing the value of the private key to that other > Holder. > > In that case, key binding does not provide a proof of *possession* of a > > private key (PoP) but only a proof of *use* of a private key (PoU). > > Collaborative attacks between "colluding user and Holders", which imply > the > > use of Holders specifically developed to cheat a Verifier should be > > mentioned. This should also be addressed using an additional section > under > > section 9 (Security Considerations). **It is thus proposed to add a > > section 9.13 about Collaborative attacks between **colluding users and > > Holders* > > > > > > > > > > *. The text change proposals for the others sections will be presented > > afterwards. Text proposal: 9.13 Collaborative attacks between **colluding > > users and Holders* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * If two users accept to collaborate, the Holder used by one user can > > perform cryptographic computations for the benefit of another Holder. > > For example, an application (i.e., a Holder) developed by a specialist > > can be downloaded by each user. If that application is able to use > the > > private keys from an original Holder, the second Holder can perform > > cryptographic computations for the benefit of another Holder. An > > example scenario is as follows: a Holder A connects to a Verifier and > > receives back a challenge and a list of claim types that it will need > to > > present to get an access. The Holder A forwards to a Holder B the > > challenge received from the Verifier, the name of the Verifier and the > > set of claim types and values that it wishes to present to the > > Verifier. The Holder A receives back from the other Holder B the data > > structure that the Holder A needs to present to get an access to that > > Verifier. The Holder A forwards it to the Verifier and gets the > access. > > Another example scenario is as follows: if private keys can be > > exported from the Holder with the user consent and then used by > another > > Holder, impersonation of the user can be achieved by the second Holder -- _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
