jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-privacypass-protocol

Commentary: cc . 
 LGTM
We deliberately avoid the usage of smaller ciphersuites (associated
with P-256 and curve25519) due to the potential to reduce security to
unfavourable levels via static Diffie Hellman attacks.  See I-D.irtf-
cfrg-voprf for more details.
Note that we must run the verifiable version of the protocol in I-
D.irtf-cfrg-voprf.  Therefore the "server" takes the role of the
"Server" running in "modeVerifiable".  In other words, the "server"
runs "(ctxtI, pkS) = SetupVerifiableServer(suite)"; where "suite" is
one of the ciphersuites in voprf-ciph-recs, "ctxt" contains the
internal VOPRF server functionality and secret key "skS", and "pkS"
is the server public key.  Likewise, run "ctxtC =
SetupVerifiableClient(suite)" to generate the Client context.
We deliberately avoid the usage of smaller ciphersuites (associated
with P-256 and ristretto255) due to the potential to reduce security
to unfavourable levels via static Diffie Hellman attacks.  See I-
D.irtf-cfrg-voprf for more details.
Note that we must run the verifiable version of the protocol in I-
D.irtf-cfrg-voprf.  Therefore the "server" takes the role of the
"Server" running in "modeVerifiable".  In other words, the "server"
runs "ctxtS = SetupVerifiableServer(suite, skS, pkS)"; where "suite"
is one of the ciphersuites in voprf-ciph-recs, "skS" and "pkS" is the
server's secret and public key respectively (generated by calling
"KeyGen").  It returns "ctxtS", which is the Server context.
Likewise, run "ctxtC = SetupVerifiableClient(suite, pkS)" to generate
the Client context.
Draft: draft-davidson-pp-architecture

Commentary: cc 
 Yeah , I agree . Something to bring up for discussion . 
 LGTM , 1 week might still be too small of a window for actively malicious servers , but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations .
With an active user-base, a week gives a fairly large window for
clients to participate in the Privacy Pass protocol and thus enjoy
the anonymity guarantees of being part of a larger group.  The low
ceiling of 12 weeks prevents a key compromise from being too
destructive.  If a server realizes that a key compromise has occurred
then the server should sample a new key, and upload the public key to
the key registry; invoking any revocation procedures that may apply
for the old key.
We highlighted previously that short key-cycles can be used to reduce
client privacy.  However, regular key rotations of the issuing key
are still recommended to maintain good server key hygiene.
We recommend that Privacy Pass issuing keys are rotated from anywhere
between 1 and 12 weeks.  With an active user-base, a week gives a
fairly large window for clients to participate in the Privacy Pass
protocol and thus enjoy the anonymity guarantees of being part of a
larger group.  The low ceiling of 12 weeks prevents a key compromise
from being too destructive.  If a server realizes that a key
compromise has occurred then the server should sample a new key and
upload the public key to the key registry; invoking any revocation
procedures that may apply for the old key.
Draft: draft-davidson-pp-protocol

Commentary: Rewrite parts of intro Clean up protocol overview Rewrite API functions Rewrite protocol instantiation Update ciphersuites ( This is a big change , apologies ! ) cc for reviews ( will also notify mailing list ) . 
 API has been updated at quite substantially . 
 SecretKey , to me , implies a symmetric key . Can we make this PrivateKey ? That 's the terminology used ( mostly ) in  , at least . 
 Done in
For this functionality, note that we supply multiple tokens in "msg"
to "Evaluate".  This allows batching a single proof object for
multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf
only permits a single input, we follow the advice for providing
vectors of inputs.
Similarly to "Issue", we follow the advice for providing vectors of
inputs to the "Unblind" function for verifying the batched proof
object.
Draft: draft-davidson-pp-protocol

Commentary: These functions do not need the " PP _ " namespace prefix as it 's implied from the specification . I also removed underscores in favor of normal camel case notation .
Run by the client when processing the server response in the issuance
phase of the protocol.  The output of this function is an array of
"RedemptionToken" objects that are unlinkable from the server's
computation in "PP_Issue".
Run by the client when processing the server response in the issuance
phase of the protocol.  The output of this function is an array of
"RedemptionToken" objects that are unlinkable from the server's
computation in "Issue".
The adversary runs "PP_Server_Setup" and generates a key-pair
"(key, pub_key)".
The adversary runs "PP_Issue" using the key-pair that it generated
on each of the client messages in the issuance phase.
The adversary runs "ServerSetup" and generates a key-pair "(key,
pub_key)".
The adversary runs "Issue" using the key-pair that it generated on
each of the client messages in the issuance phase.
A server is created that runs "PP_Server_Setup" and broadcasts the
"ServerUpdate" message "s_update".
The adversary runs "PP_Client_Setup" on "s_update".
A server is created that runs "ServerSetup" and broadcasts the
"ServerUpdate" message "s_update".
The adversary runs "ClientSetup" on "s_update".
"PP_Issue": Run on the contents of the client message in the
issuance phase.
"PP_Verify": Run on the contents of the client message in the
redemption phase.
"PP_Client_Setup": Generates the client configuration based on
the configuration used by a given server.
"PP_Generate": Generates public and private data associated
with the contents of the client message in the issuance phase.
"PP_Process": Processes the contents of the server response in
the issuance phase.
"PP_Redeem": Generates the data that forms the client message
in the redemption phase.
"Issue": Run on the contents of the client message in the
issuance phase.
"Verify": Run on the contents of the client message in the
redemption phase.
"ClientSetup": Generates the client configuration based on the
configuration used by a given server.
"Generate": Generates public and private data associated with
the contents of the client message in the issuance phase.
"Process": Processes the contents of the server response in the
issuance phase.
"Redeem": Generates the data that forms the client message in
the redemption phase.
Run "(cfg, update) = PP_Server_Setup(id)".
Run "(cfg, update) = ServerSetup(id)".
Draft: draft-davidson-pp-protocol

Commentary: Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest , respectively . Rename SecretKey to PrivateKey . Change to an integer value , rather than opaque vector . I also removed company - specific information , which is not really relevant for the document . ( That 's useful information , but not appropriate for a standards document , I think . ) cc
The Internet performance company Cloudflare has already implemented
server-side support for an initial version of the Privacy Pass
protocol PPSRV, and a client-side implementations is also available
PPEXT.  More recently, a number of applications have been built upon
the protocol, or upon slight variants of it; see: TRUST, OpenPrivacy,
PrivateStorage.  The protocol can be instantiated using a
cryptographic primitive known as a verifiable oblivious pseudorandom
function (VOPRF) for implementing the authorization mechanism.  Such
VOPRF protocols can be implemented over prime-order groups, and
constructions are currently being drafted in separate standardization
processes I-D.irtf-cfrg-voprf.
The "SecretKey" and "PublicKey" types are just wrappers around byte
arrays.
The "PrivateKey" and "PublicKey" types are just wrappers around byte
arrays.
The "ClientIssuanceMessage" struct corresponds to the message that
the client sends to the server during the issuance phase of the
protocol (issuance-phase).
The "ClientIssuanceRequest" struct corresponds to the message that
the client sends to the server during the issuance phase of the
protocol (issuance-phase).
The value of "n" is determined by the length of the
"ClientIssuanceElement" vector in the "ClientIssuanceRequest" struct.
The internal data types are described below.
The "RedemptionMessage" struct consists of the data that is sent by
the client during the redemption phase of the protocol (redemption-
phase).
The "ServerRedemptionResponse" struct corresponds to a boolean value
that indicates whether the "ClientRedemptionMessage" sent by the
client is valid.  It can also contain any associated data.
The "RedemptionRequest" struct consists of the data that is sent by
the client during the redemption phase of the protocol (redemption-
phase).
The "ServerRedemptionResponse" struct corresponds to a boolean value
that indicates whether the "ClientRedemptionRequest" sent by the
client is valid.  It can also contain any associated data.
"issuance_message": A "ClientIssuanceMessage" struct.
"issuance_request": A "ClientIssuanceRequest" struct.