Draft: draft-ietf-privacypass-protocol

Commentary: This link is broken in a few ways . Note that the links has an trailing period in it , which is only part of the problem there ; there is no Section 5.1.2 or Section " 5.1.2 . " . Also , the function is called " BlindSign " in that version of the draft . 
 In the issuance protocol draft , there are a few places where it is assumed that a value will be a certain length , but no effort has been made to explicitly set a length . In : Is the 0x0002 two octets ? Sure , you might readily assume that , but nothing says that explicitly . The same assumption appears in Sections 5.1 and 5.5 .
Unless otherwise specified, this document encodes protocol messages
in TLS notation from TLS13, Section 3.  Moreover, all constants are
in network byte order.
Unless otherwise specified, this document encodes protocol messages
in TLS notation from Section 3 of TLS13.  Moreover, all constants are
in network byte order.
Issuers provide a Private and Public Key, denoted "skI" and "pkI"
respectively, used to produce tokens as input to the protocol.  See
issuer-configuration for how this key-pair is generated.
This section describes a variant of this issuance protocol for
producing privately verifiable tokens using the protocol in OPRF.  In
particular, this variant of the issuance protocol uses the
OPRF(P-384, SHA-384) ciphersuite.
In this variant, Issuers provide a Private and Public Key, denoted
"skI" and "pkI" respectively, used to produce tokens as input to the
protocol.  See issuer-configuration for how this key-pair is
generated.
This section describes a variant of the issuance protocol in private-
flow for producing publicly verifiable tokens.  It differs from the
previous variant in that the output tokens are publicly verifiable by
anyone with the Issuer Public Key.
This means any Origin can select a given Issuer to produce tokens, as
long as the Origin has the Issuer public key, without explicit
coordination or permission from the Issuer.  This is because the
Issuer does not learn the Origin that requested the token during the
issuance protocol.
This section describes a variant of the issuance protocol in private-
flow for producing publicly verifiable tokens using the protocol in
BLINDRSA.  In particular, this variant of the issuance protocol works
for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-
Deterministic blind RSA protocol variants described in Section 5 of
BLINDRSA.
The publicly verifiable issuance protocol differs from the protocol
in private-flow in that the output tokens are publicly verifiable by
anyone with the Issuer Public Key. This means any Origin can select a
given Issuer to produce tokens, as long as the Origin has the Issuer
public key, without explicit coordination or permission from the
Issuer.  This is because the Issuer does not learn the Origin that
requested the token during the issuance protocol.
The rsabssa_blind function is defined in BLINDRSA, Section 5.1.1..
The Client stores the nonce and challenge_digest values locally for
use when finalizing the issuance protocol to produce a token (as
described in public-finalize).
The PrepareIdentity and Blind functions are defined in Section 4.1 of
BLINDRSA and Section 4.2 of BLINDRSA, respectively.  The Client
stores the nonce and challenge_digest values locally for use when
finalizing the issuance protocol to produce a token (as described in
public-finalize).
The rsabssa_blind_sign function is defined in BLINDRSA,
Section 5.1.2..  The Issuer generates an HTTP response with status
code 200 whose content consists of TokenResponse, with the content
type set as "application/private-token-response".
The Token.nonce value is that which was sampled in private-request.
If the rsabssa_finalize function fails, the Client aborts the
protocol.
The Issuer generates an HTTP response with status code 200 whose
content consists of TokenResponse, with the content type set as
"application/private-token-response".
The Token.nonce value is that which was sampled in private-request.
If the Finalize function fails, the Client aborts the protocol.