Is this message, sent to the oauth list, different than what is here: https://mailarchive.ietf.org/arch/msg/last-call/o9mStgXOwCEAZGcPlf-t_UrLmtU/ ???
Multiple comments, sent to multiple locations just makes it all confusing. I would prefer a single, concise list of comments, please. I will action this once I have the definitive list of all comments you wish to make on this draft. Deb On Wed, Apr 23, 2025 at 5:43 AM Denis <denis.i...@free.fr> wrote: > > Unless I missed an email, I have not yet seen responses to address the > comments I have posted on April 14 during the IESG Last Call > on draft-ietf-oauth-selective-disclosure-jwt-17.txt within the dead line. > > I believe that some comments are important as they highlight the fact > that, as currently described, the document does not identify some security > attacks > that make the protocol insecure. At the very minimum, the attacks should > be mentioned in the Security Considerations section. > *See comment A. * > Another major security issue is the replay detection mechanism for a > Verifier which, as currently described, is incorrect as it cannot handle > the two methods that can be used to detect replays: either "unique > numbers" generated by the Holder or "challenges" generated by the Verifier. > > When "unique numbers" are used, the Holder does *not* need to use the iat > time. Hence, the iat time should not be "REQUIRED > but should rather be "CONDITIONAL". Either "unique numbers" generated by > the Holder or "challenges" generated by the Verifier > should be accepted by a Verifier (obviously only if previously the > Verifier has sent a challenge to the Holder). > When both methods are handled, the data that will need to be kept and > managed by the Verifier during a time window will be quite different. > The time windows to handle each method can be different, hence two time > windows may be considered by the Verifier. *See Comment B*. > > For your convenience, I have added in *BOLD RED* information to indicate > either whether the comment is a new comment > or is a follow-up of a previous issue. In the later case, I have indicated > the number of the issue that has been previously raised. > > Denis > > > 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. 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. * > * 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* > > *. C. **SD-JWT SUSPENSION OR REVOCATION IS MISSING* > > * (See comment 7) D. **UNLINKABILITY** It is important to introduce the > term "one**-time-use digital **credential" (See **comment 8)* > > *. * > *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).* > > > * 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).* > > > > > > > * G. ARRAY ELEMENTS. Various comments (See comments 11 and 12). H. KEY > PAIR GENERATION AND LIFECYCLE MANAGEMENT (See a minor comment 13). I. > EDITORIAL COMMENTS (See comments 14 to 17). * > > > * > =========================================================================== > **COLLUDING HOLDERS AND USERS* > > *#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>* > > > * 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. > It is outside the scope of this document to specify how a Verifier > can know whether appropriate characteristics or properties are > effectively used by a Holder to ensure that collaborative attacks cannot > be performed between Holders. KEY BINDING* > > *#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>* > > > > > * 2. On page 4, the text states: * > > > > > > * To prevent attacks in which an SD-JWT is presented to a Verifier > without the Holder's consent, this specification additionally defines a > mechanism for binding the SD-JWT to a key under the control of the > Holder (Key Binding). When Key Binding is enforced, a Holder has to > prove possession of a private key belonging to a public key contained in > the SD-JWT itself. * > > > > > > > *The private key is only presumed to be under the control of the Holder. > The protocol does not allow to demonstrate that it is really the case, > since the characteristics of the Holder are unknown to the Verifier. A > Verifier can only check that a Holder has been able to *use* a private key > associated with a public key contained in a SD-JWT. * > > *Text change proposal: * > > > > > * This specification defines a mechanism for binding the SD-JWT to a > key that is presumed to be under the control of the Holder (Key > Binding). When Key Binding is enforced, a Verifier can check that a > Holder has been able to use a private key associated with a public key > contained in the SD-JWT. * > > > > * 3. On page 6, the text states: * > > > > > * Key Binding: Ability of the Holder to prove possession of an SD-JWT > by proving control over a private key during the presentation. > When utilizing Key Binding, an SD-JWT contains the public key > corresponding to the private key controlled by the Holder (or a > reference to this public key). * > > > > > *Key Binging only allows to demonstrate that a private key that is > associated with a public key placed into a SD-JWT has been correctly used. > It does not allow to known that the private key is indeed *possessed* by a > Holder, since characteristics of the Holder are unknown to the Verifier. * > > *Text change proposal: * > > > > > > > * Key Binding: Ability of the Holder to prove the ability to use a > private key associated with a public key contained in an SD-JWT > by using this private key during the presentation. When utilizing > Key Binding, an SD-JWT contains the public key corresponding to the > private key used by the Holder (or a reference to this public key). * > *4.** On page 43, section * > > > > > > > > *9.5. Key Binding states: Key Binding aims to ensure that the presenter > of an SD-JWT credential is actually the Holder of the credential. An > SD-JWT compatible with Key Binding contains a public key, or a reference > to a public key, that corresponds to a private key possessed by the > Holder. The Verifier requires that the Holder prove possession of that > private key when presenting the SD-JWT credential. * > * It is well known that the wording "* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *prove possession of a private key" has been used for years. However, > strictly speaking the use of the word "possession" is incorrect. From a > Verifier point of view, a correct SD-JWT+KB proves the *use* of the private > key associated with a public binding key contained in a Key Binding JWT and > it does not necessarily prove the *possession* of it (See comment 1). This > private key can *EITHER* be used by the (legitimate) Holder *OR* can be > used by the Holder for the benefit of another Holder (see the example in > the previous comment). When using the protocols described in this document, > it is impossible for a Verifier to make the distinction between these two > cases. The document is implicitly considering (without never stating it) > that Holders and users are "honest", whereas this will not necessarily be > the case. The document considers "colluding Verifiers and Issuers" but does > not consider "colluding Holders and users" which can also exist. Therefore > this is a major security issue which has not been identified and that makes > this protocol insecure. A false sense of security might be inferred when > implementing this document. This should be said. Text change proposal: > An SD-JWT compatible with Key Binding contains a public key, or a > reference to a public key, that corresponds to a private key that can be > used by a Holder either for its own benefit or for the benefit of > another Holder. When presenting a key Binding JWT, the Verifier > requires that the Holder demonstrates the use of the private key. * > > > > * 5. On page 12. Section 4.1.2, the text states: * > > * It is out of the scope of this document to describe how the Holder > key pair is established. * > > > > *This text is fine. However, it would be useful to add that it is also out > of the scope of this document to describe how the private key is protected > and usable by the Holder under the control of the user. * > > *Text change proposal: * > > > * It is out of the scope of this document to describe how the Holder > key pair is established and how the private key is protected and usable > by the Holder under the control of the user. * > > * REPLAY DETECTION OF a **Key Binding JWT* > > *#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>* > > > * 6. Section * > > > > > > > > > > > > > > > > > *4.3. Key Binding JWT states: The Key Binding JWT MUST be a JWT > according to [RFC7519] and its payload MUST contain the following > elements: * (...) * in the JWT payload, - iat: REQUIRED. > The value of this claim MUST be the time at which the Key Binding > JWT was issued using the syntax defined in [RFC7519]. - > nonce: REQUIRED. Ensures the freshness of the signature. The > value type of this claim MUST be a string. How this value is > obtained is up to the protocol used and out of scope of this > specification. * > > * This description does not allow to interoperate in a secure fashion in > particular while reading section **7.3. Verification by the Verifier* > > > > > > *. How replay *detection* can be done is not described in the document. > Note: While replay *prevention* cannot be done, replay *detection* can be > done. Whatever technique is being used, the Verifier must maintain some > states during a time window. Two techniques can be used. Each one has > advantages and inconveniences. * > > > *If correctly implemented, both techniques provide the same replay attack > detection guarantees. The choice of the appropriate technique will be > context dependant. * > > > > > > > > > > > > > > > > > > *This means that the document should describe these two techniques. A > Verifier MUST support these two techniques. However, a Holder MAY only > support one of these two techniques. Note: The kind of data that will need > to be kept by the Verifier during the time window will be dependent upon > the technique being used. For each technique, the time window can be > different. These two techniques have been described in detail in the > following issued that was initially raised by Christian. > https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104 > <https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104> > In a client - server paradigm, there exist two mechanisms that are able to > *detect* replay attacks either: - using "unique numbers" generated and > sent by a client to a server, or - using "challenges" generated and > sent by a server to a client. Unique numbers which are generated by a > Holder shall be non-repeating for ever. In practice, such requirement can > be supported by using two parameters: * > > * - the time at which the **Key Binding JWT* > > > > > > > > > > > > * ("iat" claim) has been generated and - a random number ("rnd" claim) > that needs to be unique only during a short time-window. This means that > for using unique numbers, the Holder is required to support a clock > synchronised with UTC. Challenges generated by a Verifier need to be unique > only during a short time-window. This means that for using challenges, the > Holder is not required to support a UTC synchronised with UTC. This leads > to consider the following three claims: "iat", "rdn" (for random number) > and "chal" (for challenge). The text quoted at the beginning of this > comment should be changed into: * > > > > > > > > > > > > > > * The Key Binding JWT MUST be a JWT according to [RFC7519] and its > payload MUST contain the following elements: * (...) * in the JWT > payload, - iat: CONDITIONAL. The value of this claim MUST be the > time at which the Key Binding JWT was issued using the syntax > defined in [RFC7519]. - rdn: CONDITIONAL. Ensures the > freshness of the signature and allows to detect replays. The > value type of this claim MUST be a string generated by the Holder. > * > > > > * - chal: CONDITIONAL. Ensures the freshness of the signature and > allows to detect replays. The value type of this claim MUST be > a string generated by the Verifier. * > > > *EITHER, both the "iat" and the "rdn" claims MUST be present OR the "chal" > claim MUST be present. Then after, the text from **section **7.3. > Verification by the Verifier on p**age 35 * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *would need to be fixed. Below is an extract from the current text: To > this end, Verifiers MUST follow the following steps (or equivalent): > 1. (...) 5. If Key Binding is required: 1. (...) > (...) 5. Check that the creation time of the Key Binding JWT, as > determined by the iat claim, is within an acceptable window. > 6. Determine that the Key Binding JWT is bound to the current > transaction and was created for this Verifier (replay > protection) by validating nonce and aud claims. Text change proposal: To > this end, Verifiers MUST follow the following steps (or equivalent): > 1. (...) 5. If Key Binding is required: 1. (...) > (...) 5. Determine that the Key Binding JWT is bound to the current > transaction and was created for this Verifier by validating > the aud claims. 6. Check that the Key Binding JWT is not > a replay of previously accepted JWT by checking first whether a* > * "rdn" claim or a "chal" claim is present. If none is > present, then * > > > *the Key Binding JWT shall be rejected. 7. If a * > *"rdn" claim is present, then the "iat" claim shall also be > present, otherwise the* > > * Key Binding JWT shall be rejected. The Verifier shall choose > a time-window to verify pairs of **"rdn" and "iat" claims and > maintain a list of* > > > > *validated pairs of "iat" and "rdn" claims. a) If > a received "iat" claim is outside of this time-window, > then the** Key Binding JWT shall be rejected* > > > > > > * and the Verifier should respond with an error. > b) If a received "iat" claim is inside this time window > and the values both of "iat" claim and of the associated > "rdn" claim are already present in the list of validated > pairs of "iat" and a "rdn" claims, then the* > * Key Binding JWT shall be rejected* > > > > > > > > * and the Verifier should respond with an error. > c) If a received "iat" claim is inside this time-window > and the values both of "iat" claim and of the > associated "rdn" claim are not already present in the > list of validated pairs of "iat" and a "rdn" claims, > and the associated "rdn" claim can successfully be used > to validate a **Key Binding JWT* > > > > > > > > > *, then the Verifier shall add the values both of "iat" > claim and the associated "rdn" claim into a list of > validated pairs of "iat" claim and "rdn" claim. > When the value of a "iat" claim from an entry falls > outside of the time-window, the Verifier can remove the > entry from the list. ** 8. If a **"chal" claim > is present, then the Verifier* > > > > > > * shall check whether the received challenge has previously > been generated and sent to a Holder. The Verifier shall > maintain a list of sent challenges to Holders during a > time-window chosen by itself. * > * a) If a received "chal" claim is not present in the list, > then the** Key Binding JWT shall be rejected* > > > * and the Verifier should respond with an error. > b) If a received "chal" claim is present in the list and* > * can be successfully used to validate a **Key Binding > JWT* > > > *, then the Verifier shall remove this value from the > list of challenges. Otherwise, the value must remain at * > > > > * least until the end of the time-window. > Note: In order to manage the removal of old challenges by > the Verifier, it is recommended that the Verifier locally > associates a time of issuance with each challenge.* > > *It is now necessary to fix the text from section * > > > > > > > > > > > > > > > > > > > > > > > > > > > *7.2. Processing by the Holder. Below is an extract from the current text: > (...) For presentation to a Verifier, the Holder MUST perform the > following (or equivalent) steps (in addition to the checks described in > Section 7.1 performed after receiving the SD-JWT): 1. Decide which > Disclosures to release to the Verifier, obtaining proper consent if > necessary. 2. Verify that each selected Disclosure satisfies one of the > two following conditions: 1. The hash of the Disclosure is > contained in the Issuer-signed JWT claims 2. The hash of > the Disclosure is contained in the claim value of another > selected Disclosure 3. Assemble the SD-JWT, including the Issuer-signed > JWT and the selected Disclosures (see Section 4 for the format). > 4. If Key Binding is not required: 1. Send the SD-JWT to the > Verifier. 5. If Key Binding is required: 1. Create a Key > Binding JWT tied to the SD-JWT. 2. Assemble the SD-JWT+KB by > concatenating the SD-JWT and the Key Binding JWT. 3. > Send the SD-JWT+KB to the Verifier. * > > > * It can be seen that in step 5, there is no guidance on how replay > detection should be handled by the Holder. * > > > > > *Text change proposal for step 5: 5. If Key Binding is required: > 1. Decide whether replay detection by the Verifier will be > checked using * > *"unique numbers" generated by the client or "challenges" > generated by the **Verifier* > *. Using "challenges" generated by the * > > > *Verifier will only be possible if a challenge has been > previously received from the Verifier. 2. If the Holder chooses to > use * > > > *"unique numbers", it shall be able to use a UTC clock and to > generate a random number, and shall place two values > respectively into the "iat" claim and the "rnd" claim.* > > * 3. If the Holder chooses to use * > > *"challenges", it shall place the received challenge into the > "chal" claim. * > > > > > * 4. Assemble the SD-JWT+KB by concatenating the SD-JWT and the > Key Binding JWT. 5. Send the SD-JWT+KB to the Verifier. * > > *SD-JWT SUSPENSION OR REVOCATION IS MISSING* > > *#510 Verification steps for the KB-JWT are missing in section 7.1 > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/510>* > > > * 7. Checking SD-JWT suspension or revocation is missing in section 7.1 > (**Verification > of the SD-JWT)* > > > * Steps 6 is currently described as follows: * > > * 6. Check that the SD-JWT is valid using claims such as nbf, iat, and > exp in the processed payload. If a required validity-controlling > claim is missing (see Section 9.7), the SD-JWT MUST be rejected.* > > > > > > > * None of the checks that are described is about the checking the status > of the SD-JWT, e.g., whether it has been suspended or revoked. Add the > following step: ** 7. Check that the status of the SD-JWT is valid,* > > > * e.g., whether it has been suspended or revoked. The way this can > be accomplished is out of the scope of this document. * > > *UNLINKABILITY* > > *NEW COMMENT* > > > > * 8. On page 48, the text states: * > > > > * Verifier/Verifier unlinkability and presentation unlinkability can be > achieved using batch issuance: A batch of credentials based on the > same claims is issued to the Holder instead of just a single > credential. The Holder can then use a different credential for each > Verifier or even for each session with a Verifier. * > > > > > > > > * This description is missing to indicate the major characteristic of a > SD-JWT when batch issuance is being used: each SD-JWT shall only be used > once. The batch includes a set of one-time-use SD-JWTs, each one with a > different content, including a public binding key when key binding is being > used. The term "**one** time-use digital **credential" should be added > into the text.* > > > > * Change proposal: * > * Verifier/Verifier unlinkability and presentation unlinkability can be > achieved using batch issuance: a batch of one* > *-time-use digital * > *credentials based on the same claims can be issued to the Holder > instead of just a single **digital * > *credential. The Holder can then use a different **digital * > *credential for each Verifier or even for each session with a > Verifier. * > > *One time-use SD-JWTs shall have a different content, including a > different public binding key when key binding is supported.* > > > > * POST-QUANTUM RESISTANCE KEY BINDING ALGORITHMS * > > > *#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* > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/529> > > * 9. It is proposed to add a section about Post-Quantum resistance to > section 9 (Security Considerations). This text proposal comes from the > observation that OTS **(One-Time Signatures) * > *algorithms are well suited to be used with **one**-time-use digital * > *credentials. * > > > > > * Text proposal: 9.15 Post-Quantum resistant key binding algorithms * > > > > > > > > * Implementations of SD-JWT rely on asymmetric cryptographic keys. > This document does not mandate the use of particular key binding > algorithm. It can be observed that Elliptic Curve Digital Signature > Algorithm (ECDSA) which offers a variant of the Digital Signature > Algorithm (DSA) which uses elliptic-curve cryptography, by construction, > cannot be resistant to Post-Quantum computers. Alternative algorithms > or techniques (e.g., ZKP) that would be **Post-Quantum resistant * > > > *are being explored. When using batches of **single time-use > **credentials > (see section * > *10.1), it is possible to use * > > > > > > > > > > > > > > > > > > > > *asymmetric key algorithms that are considered to be post-quantum > resistant. If the private "Binding Key“ is only used once, then the key > binding algorithm can Post-Quantum resistant. This will be the case when > using OTS (One-Time Signatures) and inserting the public key of a > Winternitz - One-Time Plus (WOTS+) algorithm into a one-time-use digital > credential. In case of a lack of Internet access, batches of "one-time > use digital credentials” should be requested in advance. > Interoperability is possible by choosing one (or more) out of seven > WOTS+ algorithm identifiers that have been registered by IANA. See: > https://www.iana.org/assignments/xmss-extended-hash-based > <https://www.iana.org/assignments/xmss-extended-hash-based>- > signatures/xmss-extended-hash-based-signatures.xhtml These algorithms > are described in [RFC8391], section 5.2 and in [SP 800-208] section 5. * > *VOCABULARY* > > *#495 The definition of an Holder would need to be reworded > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/495>* > > > > > * 10. On page 6, the text states: * > > > > > > > * Holder: An entity that received SD-JWTs from the Issuer and has > control over them. In the context of this document, the term may > refer to the actual user, the supporting hardware and software in > their possession, or both. The document only defines a subset of > protocols between three entities. Figure 1 does not describe the > interactions between the Holder software and hardware and a human user.* > > > > * Text change proposal: * > > > > > > * Holder: An entity that received SD-JWTs from the Issuer and > optionally holds the associated private keys and has control over > them. In the context of this document, the term refers to the > supporting software and hardware. ARRAY ELEMENTS* > > *NEW COMMENT* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * 11. On page 14. Section 4.2.2, the text states: For example, a > Disclosure for the second element of the nationalities array in the > following JWT Claims Set: { "nationalities": ["DE", "FR"] } > could be created by first creating the following array: > ["lklxF5jMYlGTPUovMNIvCA", "FR"] The resulting Disclosure would be: > WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0 This example is interesting, > but is not fully privacy preserving. It allows to know that a user has two > nationalities. In order to be hide this characteristic, a fixed number of > values should be used instead by the Issuer and when a user has less than > this maximum number of nationalities, some values would need to be > duplicated. For example, if a maximum number of nationalities is 3 and the > user has only one nationality, the following array should be used: { > "nationalities": ["FR", "FR", "FR"] } This issue should be > mentioned here while the solution might be detailed later on, e.g., in > section 4.2.5. Decoy Digests. * > > > > > * 12. * > > *#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>* > > > > > > > > > > > > > > > > > > > > > > > > > * On page 17. Section 4.2.5. Decoy Digests, the text states: Decoy > digests MAY be added both to the _sd array for objects as well as in > arrays. (...) To ensure readability and replicability, the examples > in this specification do not contain decoy digests unless explicitly > stated. Decoy digests work differently whether they apply to the _sd array > for objects or to an array. This difference is not explained but should be > explained. Duplicated values in an array is a means to hide the number of > really significant values in an array. See the example above about: { > "nationalities": ["FR", "FR", "FR"] } This consideration should be > added into section 4.2.6. Recursive Disclosures. KEY PAIR GENERATION AND > LIFECYCLE MANAGEMENT* > > *NEW COMMENT* > > * 13. On page 46, Section * > > > > > > > > > > *9.12. Key Pair Generation and Lifecycle Management states: > Implementations of SD-JWT rely on asymmetric cryptographic keys and must > therefore ensure that key pair generation, handling, storage, and > lifecycle management are performed securely. While the specific > mechanisms for secure key management are out of scope for this document, > implementers should follow established best practices, such as those > outlined in NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5]. * > > > * Following this Recommendation is certainly useful, but might lead to a > false sense of security. On Page 15 from [NIST.SP.800-57pt1r5], the Owner > (of a key or key pair) is defined as: * > > * "For a static key pair, the entity that is associated with the > public key and authorized to use the private key".* > > > > > > > > > > > * The entity that is associated with the public key and authorized to use > the private key may use the private key either in an "honest" way or in a > "dishonest" way. As long as the private key is used in an "honest way", > there is no problem, but in the context of this draft it is possible to > disclose a single claim without being identified. The use of private > binding keys should be restricted to "honest" appropriate applications. It > is proposed to add the following text at the end of section 9.12: While > best practices for an * > > *appropriate key management are essential, in the context of this > document, while necessary, they are insufficient. In particular, a * > *private binding key should only be usable by an "honest" appropriate > application. * > > > > * EDITORIAL COMMENTS * > * 14. * > > *NEW COMMENT* > > > > * EDITORIAL change: On page 6, the text states: * > > > > * Selectively Disclosable JWT (SD-JWT): A composite structure, > consisting of an Issuer-signed JWT (JWS, [RFC7515]) and zero or more > Disclosures, which supports selective disclosure as defined in this > document. * > * An * > > *SD-JWT is issued to a user. It would be useful to state that the claims > in the SD-JWT relate to a user that, later on, will be able to consent to > selectively disclose some claims. Hence the words "issued to a user" have > been added.* > > > > * Text change proposal: * > > > > > * Selectively Disclosable JWT (SD-JWT): A composite structure, > consisting of an Issuer-signed JWT (JWS, [RFC7515]) issued to a user > and zero or more Disclosures, which supports selective disclosure as > defined in this document. * > * 15. * > > *NEW COMMENT* > > * EDITORIAL change: On page 19, in **Section 4.3. Key Binding JWT* > * the text states: * > > > > > > > * This section defines the Key Binding JWT, which encodes a signature > over an SD-JWT by the Holder's private key. A Holder can have more that > one private key, hence the article "a" should be used instead of the > article "the". * > *Text change proposal: * > > > > > * This section defines the Key Binding JWT, which encodes a signature > over an SD-JWT by a Holder's private key. **16.* > > *NEW COMMENT* > > *EDITORIAL change. On page 47, section * > > > > > > *10.1. Unlinkability states: Unlinkability is a property whereby > adversaries are prevented from correlating credential presentations of > the same user beyond the user's consent. Without unlinkability, an > adversary might be able to learn more about the user than the user > intended to disclose, for example:* > > > > > > > * The use of the term "adversaries" looks odd as the entities are > collaborating or colluding but and are not adversaries. Change proposal: * > > > > * Unlinkability is a property whereby colluding Verifiers and/or > Issuers are prevented from correlating credential presentations of the > same user beyond the user's consent. Without unlinkability, colluding > parties might be able to learn more about the user than the user > intended to disclose, for example:* > > > *17.* > > *#520 Section 10.3 (Confidentiality during Transport) should also mention > integrity > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/520>* > > *EDITORIAL change.** On page 50, section 10.3.* > > *Confidentiality during Transport * > > > > > > > > > > > > > > > > > > > > > > > > > *Both confidentiality and integrity during Transport are essential. In > section 10.3, the text states: Usually, transport protocols for issuance > and presentation of credentials are designed to protect the confidentiality > of the transmitted data, for example, by requiring the use of TLS. This > specification therefore considers the confidentiality of the data to be > provided by the transport protocol and does not specify any encryption > mechanism. Confidentiality alone would be insufficient. It is necessary to > consider both confidentiality and integrity. Everybody is using TLS today > which supports both confidentiality and integrity. Change into: 10.3. > Confidentiality and integrity during Transport Usually, transport protocols > for issuance and presentation of credentials are designed to protect the > confidentiality and the integrity of the transmitted data, for example, by > requiring the use of TLS. This specification therefore considers the > confidentiality and the integrity of the data to be provided by the > transport protocol and does not specify any specific cryptographic > mechanism. This text is sufficient and the remaining of this section which > is copied below can be removed: * > > > > > > > * Implementers MUST ensure that the transport protocol provides > confidentiality if the privacy of user data or correlation attacks by > passive observers are a concern. To encrypt the SD-JWT when transmitted > over an insecure channel, implementers MAY use JSON Web Encryption (JWE) > [RFC7516 > <https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#RFC7516>] > by nesting the SD-JWT as the plaintext payload of a JWE. Especially, when > an SD-JWT is transmitted via a URL and information may be stored/cached in > the browser or end up in web server logs, the SD-JWT SHOULD be encrypted > using JWE. * > > *Denis* > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
