Reviewer: Alexey Melnikov Review result: Has Nits Reviewer: Alexey Melnikov Review result: Ready with nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The Privacy Pass protocol provides a privacy-preserving authorization mechanism. In essence, the protocol allows clients to provide cryptographic tokens that prove nothing other than that they have been created by a given server in the past <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture>. This document describes the issuance protocol for Privacy Pass built on HTTP. It specifies two variants: one that is privately verifiable using the issuance private key based on the oblivious pseudorandom function from <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21>, and one that is publicly verifiable using the issuance public key based on the blind RSA signature scheme <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-14>. The document is well written and easy to understand. It relies on properties of underlying mechanisms (OPRF/Blind RSA) and also references the PrivacyPass Architecture draft. So assuming these properties hold there are no extra security or privacy concerns to discuss in this document. Nits: Section 7 (Security considerations) says: In particular, Section 4 and Section 5 of [ARCHITECTURE] discuss relevant privacy considerations. Do you really mean section 4 and 5? In the Architecture document I see: 4. Deployment Models 5. Deployment Considerations 6. Privacy Considerations So at least the reference to Section 6 seems to be missing. In Sections 8.3.1-8.3.3 the media type registration template field "Applications that use this media type" has the value "N/A". This field should be describing intended use of these media types, even if there is none at the moment. This field is intended to help implementors decide whether or not they need to support a particular media type, so having it as "N/A" is unhelpful. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
