Thanks for the review John. I've tried to reply to the comments inline below.
On Sun, Jan 29, 2023 at 8:22 AM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote: > Hi, > > > > The reopened JOSE WG which I am co-chairing has in its charter to sync > with the Selective Disclosure JWT work in Oauth WG. I therefore did a > review of draft-ietf-oauth-selective-disclosure-jwt-02. > > > > Comments: > > > > - I think the document should explicitly say that it cannot be used with > JWTs protected with MACs. > It's somewhat implicitly stated now (via text like "SD-JWT is a JWT that MUST be signed using the Issuer's private key" in sec 5.2 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#name-format-of-an-sd-jwt>.) but I think you're right that it should be explicit. > 8 > > - Why would HOLDER-PUBLIC-KEY not be a claim? e.g., "cnf" or something > else? > > I assume it would be a claim. Is there something that suggests otherwise to you? That "HOLDER-PUBLIC-KEY" only shows up in section 4.3 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#section-4.3>, which is supposed to be a somewhat abstract discussion about it. And I think it's separate from SD-CLAIMS and NON-SD-CLAIMS there to call attention to it. But not to suggest that it's not a claim. More generally (as sec 5.2.3. Holder Public Key Claim <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#name-holder-public-key-claim> tries to describe) the specific way that holder public key binding is established by the issuer and represented in the JWT is out of scope. A "cnf" claim is used in examples for what it's worth. But the specific details of a holder public key binding claim are left to applications using or profiling SD-JWT. > > - The salts need to be secret. Otherwise, an attacker can guess and verify > claims. > The only purpose of the salt is to add a sufficient amount of randomness to the hash input so as to make it infeasible to "reverse" the hash value by enumerating potential claim name/values into the hash function. Correspondingly a salt value is included in the disclosure structure directly alongside a claim name and value. I think using the word secret to talk about salt values would be problematic and potentially confusing. The salt values of undisclosed claims need to be hidden from parties to whom the claim isn't being disclosed. But the salts are sent from the issuer to the holder. And salts of disclosed claims are sent from the holder to the verifier. That's different from a typical secret (as I think of a secret anyway). We can look to add text or clarify text about not revealing salt values to unintended parties. > > > - The salts need to be independent of each other. Otherwise, a Verifier > can guess claims. > There is a requirement in section 8.5 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#section-8.5-2> that the "Issuer MUST ensure that a new salt value is chosen for each claim" and a "new salt MUST be chosen for each claim" in section 8.4 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#section-8.4>. I think that's what you mean by salts being independent of each other? > > > - 128-bit entropy salts are needed to get 128-bit confidentiality. JOSE > currently has a minimum 128-bit confidentiality, I don't think SD-JWT > should change that. Salts with 128-bit entropy should be a MUST. > <http://goog_416715492> Sec 8.5 <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#name-minimum-length-of-the-salt> has a 128-bit minimum length as RECOMMENDED. As I recall, there was some desire to allow for shorter salts when used with a more computationally expensive digest function and the RECOMMENDED would allow for that situation by basically saying to use at least 128 unless you have a good reason to do otherwise and understand the implications. > > > - Salt is not a suitable name for the secret random strings. I think the > name should be changed to key or secret. > Salt might well not be the perfect name. As somewhat described previously, I think "key" or "secret" are definitely not the right name and would be more prone to mislead or confuse. It's a random value that's included in the hash input (that otherwise has a more predictable value space) to make it infeasible to guess/confirm the claim name and value from the hash value. And ensure that the hash output will vary when hashing the same claim name/value more than once. > > > - HASH(SALT, CLAIM-NAME, CLAIM-VALUE) is a keyed hash. When this > construction is used with SHA2, length extension attacks are trivial. > Length extensions of ["9KNM1LVqMOUtzFObHUxCbw", "given_name", "John"] would > probably be detected by the JSON parser but moving cryptographic > functionality to the JSON parsing is not good. Inventing new keyed hash > algorithms is not good. I think the document should be changed to use an > approved keyed hash function like HMAC or KMAC. > The hash output isn't a MAC in the SD-JWT application/use of it. Each disclosure structure (containing the claim name & value as well as the salt) is hashed and the digest value is placed in the "_sd" claim of the signed JWT. Each (signed via inclusion in the JWT) digest value is an integrity check on, and reference to, the corresponding disclosure. Length extension attacks aren't applicable to this kind of use of the hash value. Any change to the disclosure content breaks the integrity check and any change to the hash value breaks the signature. Cheers, > > John > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _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 https://www.ietf.org/mailman/listinfo/oauth
