Draft: draft-ietf-privacypass-architecture

Commentary: Replace suggested registry with list of other options . The rationale is that a registry may be sufficient but not necessary . There are other options that might work . I suggest we work with on a draft describing these techniques in more detail . cc 
 There 's currently no text around token expiration . Minimally , we could say that tokens expire when issuer ( and verifier )   . Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens ? For example , one might imagine using PMB - like constructions to encode an expiration " epoch " into the metadata bits . The single metadata bit variant would allow two epochs that way . what do you think ? 
 I 'm not sure what baking the expiry into the tokens gives that ca n't be managed by rotating the issuer / verifier keys ( or using public metadata ( which is effectively the key used to sign ) ) ? That way issuers that care about more fine grained token expiration use the key rotation for that and issuers that only care about coarse token expiration use it for other metadata , allowing the protocol to treat both in the same way ? 
 Yeah , I think the only two options are ( a ) rotate keys or ( b ) include the expiry information as public metadata ( and need not be tied to the key used to sign ) . I 'm not advocating for one or the other . Sure , that 's reasonable . We should probably have text on this point . ( That 's partly why I filed this issue . ) 
 We should also make sure to note that the validity window does narrow the anonymity set . 
 This LGTM . Agreed that working on a document that tackles these questions specifically would be worthwhile .
For reasons that we address later in privacy, the way that the server
publishes and maintains this information impacts the effective
privacy of the clients.  In this section, we describe the main
policies that need to be satisfied for a key management system in a
Privacy Pass ecosystem.
Note that we only specify a set of guidelines and recommendations for
operating a public key registry in this document.  Actual
specification of such a registry and how it operates will be covered
elsewhere.
Server's must provide their public keys to clients along with details
about the cryptographic ciphersuite that they are using.  In privacy,
we address the importance of providing clients with sources of truth
for learning the server's key configuration.
In particular, server key material MUST be publicly available in a
tamper-proof data structure, which we refer to as a key registry.  A
registry must be globally consistent.  Clients using the same
registry should coordinate in some way to ensure they have a
consistent view of said registry.  This can be done via gossiping or
some other mechanism.  The exact mechanism for this coordination will
be described elsewhere.  It is assumed there will be at least one
such mechanism.
It is RECOMMENDED that each key registry is an append-only data
structure, such as a Merkle Tree.  The key registry should be
operated independently of any server that publishes key material to
the registry.  This ensures that any client can make better
judgements on whether to trust the registry and, transitively, each
server.
While there may be multiple key registries for a given ecosystem, a
server MUST only publish its key material to a single registry.  This
ensures that the server is keeping a consistent view of its key
material.
Servers use a verifiable, tamper-free registry from which clients
discover keys.  Similar to related mechanisms and protocols such
as Certificate Transparency RFC6962, this may require external
auditors or additional client behavior to ensure the registry
state is consistent for all clients.
Clients use an anonymity-preserving tool such as Tor to discover
keys from multiple network vantage points.  This is done to ensure
consistent keys to seemingly different clients.
Clients embed server keys into software.
Specific mechanisms for key management and discovery are out of scope
for this document.
To prevent against this, servers MUST only use one private key for
issuing tokens at any given time.  Servers may use two or more keys
for redemption to allow servers for seamless key rotation.
Key rotations must be limited in frequency for similar reasons.  See
parametrization for guidelines on what frequency of key rotations are
permitted.
To prevent against this, servers MUST only use one private key for
issuing tokens at any given time.  Servers MAY use one or more keys
for redemption to allow servers for seamless key rotation.
Servers may rotate keys as a means of revoking tokens issued under
old or otherwise expired keys.  Alternatively, servers may include
expiration information as metadata alongside the token; See metadata
for more discussion about metadata constraints.  Both techinques are
equivalent since they cryptographically bind expiration to individual
tokens.
Key rotations should be limited in frequency for similar reasons.
See parametrization for guidelines on what frequency of key rotations
are permitted.
Metadata may also be arbitrarily long or bounded in length.  The
amount of permitted metadata may be determined by application or by
the underlying cryptographic protocol.