Privacy Pass Issuance Protocol
draft-ietf-privacypass-protocol-16

Thank you for the work on this document.

Many thanks to Yoshiro Yoneya for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU/ and to Mark Nottingham for his HTTP Dir review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0157.html. Thanks to the authors for addressing the comments.

Thank you for addressing my comment and posting the media type registration to the media-types list (for next time, please make it easier for readers and copy paste the whole registration request directly in your email).

Thanks for fixing the IANA stuff I mentioned.

Copied from my previous DISCUSS position about -14:

Maybe I'm missing something, but you have this in Section 6.5:

"Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation."

Version -15 goes on to say that there are no security implications of a collision (whew) but basically says the operation is invalid after that.  That leads me to think this is a strange use of SHOULD, i.e., "You SHOULD do this or things don't work."  I still don't understand why that's not a MUST.  Why might one legitimately decide not to do what this says?

Thank you to Alexey Melnikov for the SECDIR review.

Thank your for publishing -15 to address my DISCUSS and COMMENT feedback; and for the document clarifications in the ballot thread.

One final, minor editorial suggestion to improve the pointers to the to the ASN.1 objects.

OLD – Section 6.5

   The key identifier for an Issuer Private and Public Key (skI, pkI),
   denoted token_key_id, is computed as SHA256(encoded_key), where
   encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI)
   object carrying pkI as a DER-encoded RSAPublicKey value in the the
   subjectPublicKey field.  Additionally, the SPKI object MUST use the
   id-RSASSA-PSS object identifier in the algorithm field within the
   SPKI object,

NEW (i.e., add a reference to RFC5756 or RFC4055; and remove the “the the”)

The key identifier for an Issuer Private and Public Key (skI, pkI),    denoted token_key_id, is computed as SHA256(encoded_key), where    encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756]in the subjectPublicKey field.

I am traveling this week, and so relied heavily on Susan Hares' OpsDir review:  https://datatracker.ietf.org/doc/review-ietf-privacypass-protocol-12-opsdir-lc-hares-2023-09-04/

I am balloting NoObj in the "This is outside my area of expertise or have no cycles" with the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense of the term

# GEN AD review of draft-ietf-privacypass-protocol-14

CC @larseggert

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms `blinded`, `blind`, `blind_inv`, `blinded_msg`, `blindrsa`,
   `blindevaluate`, `blind_sig`, `blindsign`, and `blinded_element`;
   alternatives might be `visually impaired`, `unmindful of`, `unconcerned
   about`, `negligent of`, `unaware`, `uncomprehending`, `unaware`,
   `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 5.2, paragraph 6
```
-    If these conditions are met, the Issuer then tries to deseralize
+    If these conditions are met, the Issuer then tries to deserialize
+                                                               +
```

### Grammar/style

#### Section 4, paragraph 20
```
l, the Issuer Request URL might be correspond to the Client's configured Atte
                                ^^^^^^^^^^^^^
```
There may an error in the verb form "be correspond".

#### Section 5.5, paragraph 3
```
l, the Issuer Request URL might be correspond to the Client's configured Atte
                                ^^^^^^^^^^^^^
```
There may an error in the verb form "be correspond".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool