Draft: draft-ietf-privacypass-protocol

Commentary: Hexadecimal constants are used as strings without specifying the length or byte order . For example , " 0x0001 " might be interpreted in a couple of ways . Usually the correct interpretation is clear in context , but I 'm not sure it always is . 
 [ ] Overall : The document is inconsistent about capitalization after colon ( " : " ) . [ ] Abstract : I 'm not sure the distinction between public / private verifiability is common knowledge . It might be helpful to say plainly who is doing the verifying . E.g. : " one [ variant ] providing tokens whose validity can be verified by the issuer only ; and another for which token validity can be verified by any party with the issuer public key . " [ ] 2 Terminology : " We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire " This does n't need to be mentioned , in my opinion . [ ] 5.1 Client - To - Issuer Request : The psedocode for computing " client_context " hard - codes a particular OPRF suite ( 0x0004 ) . Is this the only suite that is permitted / recommended by the document ? I do n't think this is clear until the token types are defined in Section 8.1 . [ ] 5.3 Finalization : Constants hardcoded instructs do n't a semi - colon after the constant . ( See " Token " in this section , for example . ) Is this intentional ? It looks a bit odd , and I 'm wondering if this is " syntactically " correct . [ ] 5.4 Token Verification : I think it 's worth pointing out here that creating the server context requires the Issuer Private Key , which is why VOPRF is not publicly verifiable . [ ] 7 Security Considerations : " All security considerations described in the VOPRF document also apply in the Privacy Pass use - case . " What about security considerations for BLINDRSA ? It might be a bit cleaner to write something like this : " Each protocol described here inherits the security considerations of its base document : For Section 5 , this is [ VOPRF ] ; ... " [ ] Acknowledgements : Sofi is acknowledged , but is also a co - author . 
 I think I caught all of these . Addressed in . Yes , this is much better ! Addressed in . This is addressed by . We explain the constant in the sentence immediately following the pseudocode , so I do n't think further clarification is needed . The semi - colon was missing , but we updated this to match what 's done in RFC8446 . Addressed in . Addressed in . Good catch . This has already been fixed on the editor 's branch to say " All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use - case . "
This document specifies two variants of the the two-message issuance
protocol for Privacy Pass tokens: one that produces tokens that are
privately verifiable, and another that produces tokens that are
publicly verifiable.
This document specifies two variants of the the two-message issuance
protocol for Privacy Pass tokens: one that produces tokens that are
privately verifiable using the issuance private key, and another that
produces tokens that are publicly verifiable using the issuance
public key.
This document describes the issuance protocol for Privacy Pass built
on HTTP.  It specifies two variants: one that is privately verifiable
based on the oblivious pseudorandom function from OPRF, and one that
is publicly verifiable based on the blind RSA signature scheme
BLINDRSA.
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 OPRF, and one that is publicly verifiable using the
issuance public key based on the blind RSA signature scheme BLINDRSA.
Unless otherwise specified, this document encodes protocol messages
in TLS notation from TLS13, Section 3.
Unless otherwise specified, this document encodes protocol messages
in TLS notation from TLS13, Section 3.  Moreover, all constants are
in network byte order.
To verify a token, a verifier checks that Token.authenticator is a
valid signature over the remainder of the token input as described
below.  The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2
of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as
the PSS mask generation function (MGF), and a 48-byte salt length
(sLen).
To verify a token, a verifier checks that Token.authenticator is a
valid signature over the remainder of the token input using the
Issuer Public Key. The function "RSASSA-PSS-VERIFY" is defined in
Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1
with SHA-384 as the PSS mask generation function (MGF), and a 48-byte
salt length (sLen).