[Privacy-pass] AD review of draft-ietf-privacypass-protocol-11

[Paul Wouters <[e-mail]>]

Thanks for producing this document. It is a clear read. I have a few minor
questions and a few comments to consider for improvement.


Questions:

        Clients SHOULD NOT use a token key before this timestamp

Why is this not a MUST NOT ?

Why is token-keys not called issuer-token-list ? Brings it more in line with
issuer-request-uri and deconfuses it from token-key. This way, the top layer
is issuer-* values and the bottom layer is token-* values. Similarly, I
would
name not-before token-not-before.

        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.

So why are the token ids truncated? Why not use the full id ?

        Each key pair SHALL be generated as as specified in FIPS 186-4

Can this be rephrased as "SHALL be generated securely, for example as
specified in FIPS 186-4".
I find it a bit odd for an IETF document to require a national crypto
standard conformance.
Then you can also keep the DSS reference as informative. If the document
ends up keeping
this text, it would have to reference DSS normatively.

The DSS link https://dx.doi.org/10.6028/nist.fips.186-4 throw a warning
that it is about to
die and points to an updated reference. Use that instead?

Comments:

I find the line breaks for some table items confusing, eg:

        issuera-
        request-
        uri

People will wonder if that should read as "issuer-request-uri" or
"issuerrequesturi"
There are a number of these in the document (token-key, token-type, ?)


UNIX timestamp - Maybe refer to
https://datatracker.ietf.org/doc/html/rfc8877#section-4.2.1


        Regular rotation of token keys is recommended to minimize the risk
of key compromise.

You mean minimize the effects of a key compromise ? Or minimize the
exposure of compromised keys?


        The Issuer then tries to deseralize

Start this sentence on a new line so it becomes clearer this is not part of
the just mentioned failure path?

        The Token.nonce value is that which was sampled in

Can we say "created" instead of "sampled" ?

        Otherwise, if the Issuer is willing to produce a token token to the
Client

There is a stray "token" word in that sentence.

The document references draft-irtf-cfrg-rsa-blind-signatures-13 but -14 is
out.

The last sentence of the Security Consideration section runs on very long
and is very hard to
read. Can this be split in separate sentences?

The document references  draft-ietf-privacypass-auth-scheme-11  but -12 is
out.

In section 8.2, it refers to an IANA registry by pointing to another
document instead of just
naming the registry. This indirection is not desirable. Just reference the
IANA registry
"Privacy Pass Token Type".

draft-ietf-privacypass-key-consistency-00 is also an outdated reference, as
-01 is available.


The Shepherds write up answered the question on "required formal expert
review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews" as
"N/A" but the
document does add a number of media type registrations.


Paul