Draft: draft-ietf-privacypass-protocol

Commentary: This is a breaking change since it updates the value of the code points . Starting as a draft until I 'm able to produce matching test vectors . 
 Hm , I was thinking we 'd just fully specify the types 1 and 2 right now , rather than trying to define a bunch of different combinations up front . Is there a benefit to listing all of the combinations out ? Since for interop we want convergence on types , why not just have a very standard 1 and 2 ? 
 Convergence seems orthogonal to the values here , no ? Implementations could just pick a common type , as we 've done for ECH , HPKE , etc . It seems important to offer flexibility here for applications that might need it . 
 For the common web cases , where we have websites that want to work with the wide range of clients , I 'd prefer to see a very clear option of what to use by default — with one for privately verifiable , and one for publicly verifiable . If people have use cases that ca n't use these algorithms ( like we 've seen for IOT use cases , etc , for other protocols ) , I 'd rather see those defined when there 's a profile that has a driving use case . For example , we could end up defining a full matrix of different SHA lengths and key sizes ( they 're all 4096 right now for RSA , but we could have others ) and that seems unnecessary . 
 Well , we can RECOMMEND issuance protocols for common use cases , as we 've done for ECH . 
 Reverted type2 change ! 
 this is good to go now -- please have a look ! 
 The SPKI format is currently unspecified , and as there are multiple ways to encode an RSA public key ( and hash algorithm ) , this makes interop somewhat difficult . Moreover , the SPKI can encode any number of RSA public key sizes , in contrast to elliptic curves wherein the " suite " typically defines the key size . In the name of simplicity , I 'd propose that we have the identifier fully specify everything one needs to use the algorithm , including key size , hash algorithm , and encoding format . 
 Clarified that this would mean that each token type fully specifies the algorithms and sizes it uses . I support this . 
 Right , specifically , I think each type would specify : algorithm key ( and signature ) size key encoding There 's a large number of permutations here , e.g. , SHA-256 , 4096 - bit key , RSASSA - PSS OID   , 2048 - bit key , RSASSA - PSS OID SPKI ...
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens.  Each key
pair MUST be generated as as a valid 4096-bit RSA private key
according to [TODO].  The key identifier for a keypair (skI, pkI),
denoted "key_id", is computed as SHA256(encoded_key), where
encoded_key is a DER-encoded SubjectPublicKeyInfo object carrying
pkI.
Issuers are configured with Private and Public Key pairs, each
denoted skI and pkI, respectively, used to produce tokens.  Each key
pair SHALL be generated as as specified in FIPS 186-4 DSS.
The key identifier for a keypair (skI, pkI), denoted "key_id", is
computed as SHA256(encoded_key), where encoded_key is a DER-encoded
SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object
MUST use the RSASSA-PSS OID RFC5756, which specifies the hash
algorithm and salt size.  The salt size MUST match the output size of
the hash function associated with the public key and token type.