]> Google

ghous_amjad@alumni.brown.edu

Google

scott@shendrickson.com

Cloudflare

caw@heapingbits.net

Google

kwlyeo@cs.columbia.edu

Internet-Draft This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction specifies the RSA blind signature protocol, denoted RSABSSA. This is a two-party protocol between client and server (or signer) where they interact to compute sig = Sign(sk, input_msg), where input_msg = Prepare(msg) is a prepared version of the private message msg provided by the client, and sk is the signing key provided by the server. Upon completion of this protocol, the server learns nothing, whereas the client learns sig. In particular, this means the server learns nothing of msg or input_msg and the client learns nothing of sk. RSABSSA has a variety of applications, with being a canonical example. While useful, this protocol is limited in that it does not easily accommodate public metadata to be associated with a (message, signature) pair. In this context, public metadata is information that is publicly known to both client and server at the time of computation. This has useful applications in practice. For example, metadata might be used to encode expiration information for a (message, signature) pair. In practice, metadata can be encoded using signing key pairs, e.g., by associating one metadata value with one key pair, but this does not scale well for applications that have large or arbitrary amounts of metadata. This document specifies a variant of RSABSSA that supports public metadata, denoted RSAPBSSA (RSA Partially Blind Signature with Appendix). Similar to RSABSSA in , RSAPBSSSA is defined in such a way that the resulting (unblinded) signature can be verified with a standard RSA-PSS library.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Notation The following terms are used throughout this document to describe the protocol operations in this document:

• bytes_to_int and int_to_bytes: Convert a byte string to and from a non-negative integer. bytes_to_int and int_to_bytes are implemented as OS2IP and I2OSP as described in , respectively. Note that these functions operate on byte strings in big-endian byte order.
• random_integer_uniform(M, N): Generate a random, uniformly distributed integer R between M inclusive and N exclusive, i.e., M <= R < N.
• bit_len(n): Compute the minimum number of bits needed to represent the positive integer n.
• inverse_mod(x, n): Compute the multiplicative inverse of x mod n or fail if x and n are not co-prime.
• is_coprime(x, n): Return true if x and n are co-prime, and false otherwise.
• len(s): The length of a byte string, in bytes.
• random(n): Generate n random bytes using a cryptographically-secure random number generator.
• concat(x0, ..., xN): Concatenation of byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• slice(x, i, j): Return bytes in the byte string x starting from offset i and ending at offset j, inclusive. For example, slice(0x010203040506, 1, 5) = 0x0203040506.
• random_prime(b): Return a random prime number of length b bits.
• is_prime(p): Return true if the input integer p is prime, and false otherwise.

RSAPBSSA Protocol The RSAPBSSA protocol consists of two helper functions -- DeriveKeyPair and DerivePublicKey -- and four core functions -- Prepare, Blind, BlindSign, and Finalize -- and requires one round of interaction between client and server. Let msg be the client's private input message, info be the public metadata shared between client and server, and (sk, pk) be the server's private and public key pair. The REQUIRED key generation procedure for RSAPBSSA is specified in . The protocol begins by the client preparing the message to be signed by computing: The client then initiates the blind signature protocol by computing: The client then sends blinded_msg to the server, which then processes the message by computing: The server then sends blind_sig to the client, which then finalizes the protocol by computing: The output of the protocol is input_msg and sig. Upon completion, correctness requires that clients can verify signature sig over the prepared message input_msg and metadata info using the server public key pk by invoking the RSASSA-PSS-VERIFY routine defined in . The Finalize function performs this check before returning the signature. See for more details about verifying signatures produced through this protocol. In pictures, the protocol runs as follows: blind_sig = BlindSign(sk, blinded_msg, info) blind_sig <---------- sig = Finalize(pk, input_msg, info, blind_sig, inv) ]]> In the remainder of this section, we specify the Blind, BlindSign, and Finalize functions that are used in this protocol. The Prepare function is as specified in .

Key Generation The protocol in this document requires signing key pairs to be generated such that they satisfy a particular criteria. In particular, each RSA modulus for a key pair MUST be the product of two safe primes p and q. A safe prime p is a prime number such that p = 2q + 1, where q is also a prime number. A signing key pair is a tuple (sk, pk), where each element is as follows:

• sk = (n, p, q, phi, d), where phi = (p - 1)(q - 1), n = p * q, and d is the private exponent
• pk = (n, e), where n = p * q, and e is hte public exponent such that d * e == 1 mod phi

The procedure for generating a key pair satisfying this requirement is below. The procedure for generating a safe prime, denoted SafePrime, is below.

Blind The Blind function encodes an input message with the corresponding metadata value and blinds it with the server's public key. It outputs the blinded message to be sent to the server, encoded as a byte string, and the corresponding inverse, an integer. RSAVP1 and EMSA-PSS-ENCODE are as defined in Sections and of , respectively. If this function fails with an "blinding error" error, implementations SHOULD retry the function again. The probability of one or more such errors in sequence is negligible. This function can also fail with an "invalid input" error, which indicates that one of the inputs (likely the public key) was invalid. Implementations SHOULD update the public key before calling this function again. See for more information about dealing with such errors. Note that this function invokes RSAVP1, which is defined to throw an optional error for invalid inputs. However, this error cannot occur based on how RSAVP1 is invoked, so this error is not included in the list of errors for Blind. The blinding factor r MUST be randomly chosen from a uniform distribution. This is typically done via rejection sampling. The function DerivePublicKey is defined in .

BlindSign BlindSign performs the RSA private key operation on the client's blinded message input and returns the output encoded as a byte string. RSASP1 is as defined in .

Finalize Finalize validates the server's response, unblinds the message to produce a signature, verifies it for correctness, and outputs the signature upon success. Note that this function will internally hash the input message as is done in Blind. Note that pk_derived can be computed once during Blind and then passed to Finalize directly, rather than being recomputed again.

Verification As described in , the output of the protocol is the prepared message input_msg and the signature sig. The message that applications consume is msg, from which input_msg is derived, along with metadata info. Clients verify the signature over msg and info using the server's public key pk as follows:

1. Compute pk_derived = DerivePublicKey(pk, info).
2. Compute msg_prime = concat("msg", int_to_bytes(len(info), 4), info, msg).
3. Invoke and output the result of RSASSA-PSS-VERIFY () with (n, e) as pk_derived, M as msg_prime, and S as sig.

Verification and the message that applications consume therefore depends on which preparation function is used. In particular, if the PrepareIdentity function is used, then the application message is input_msg. In contrast, if the PrepareRandomize function is used, then the application message is slice(input_msg, 32, len(input_msg)), i.e., the prepared message with the random prefix removed.

Public Key Derivation The public key derivation function (DerivePublicKey) derives a per-metadata public key that is used in the core protocol. The hash function used for HKDF is that which is associated with the RSAPBSSA instance and denoted by the Hash parameter. Note that the input to HKDF is expanded to account for bias in the output distribution.

Key Pair Derivation The key pair derivation function (DeriveKeyPair) derives a pair of private and public keys specific to a metadata value that are used by the server in the core protocol.

Implementation and Usage Considerations This section documents considerations for interfaces to implementations of the protocol in this document. This includes error handling and API considerations.

Errors The high-level functions specified in are all fallible. The explicit errors generated throughout this specification, along with the conditions that lead to each error, are listed in the definitions for Blind, BlindSign, and Finalize. These errors are meant as a guide for implementors. They are not an exhaustive list of all the errors an implementation might emit. For example, implementations might run out of memory. Moreover, implementations can handle errors as needed or desired. Where applicable, this document provides guidance for how to deal with explicit errors that are generated in the protocol. For example, "blinding error" is generated in Blind when the client produces a prime factor of the server's public key. indicates that implementations SHOULD retry the Blind function when this error occurs, but an implementation could also handle this exceptional event differently, e.g., by informing the server that the key has been factored.

Signing Key Generation and Usage The RECOMMENDED method for generating the server signing key pair is as specified in FIPS 186-4 . A server signing key MUST NOT be reused for any other protocol beyond RSAPBSSA. In particular, the same signing key MUST NOT be used for both the RSAPBSSA and RSABSSA protocols. Moreover, a server signing key MUST NOT be reused for different RSAPBSSA encoding options. That is, if a server supports two different encoding options, then it MUST have a distinct key pair for each option. If the server public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID . It MUST NOT use the rsaEncryption OID .

RSAPBSSA Variants In this section, we define named variants of RSAPBSSA. These variants consider different sets of RSASSA-PSS parameters as defined in and explicitly specified in . For algorithms unique to RSAPBSSA, the choice of hash function specifies the instantation of HKDF in DerivePublicKey in . The different types of Prepare functions are specified in .

1. RSAPBSSA-SHA384-PSS-Randomized: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, a 48-byte salt length, and uses the randomized preparation function (PrepareRandomize).
2. RSAPBSSA-SHA384-PSSZERO-Randomized: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and uses the randomized preparation function (PrepareRandomize).
3. RSAPBSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, 48-byte salt length, and uses the identity preparation function (PrepareIdentity).
4. RSAPBSSA-SHA384-PSSZERO-Deterministic: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and uses the identity preparation function (PrepareIdentity). This is the only variant that produces deterministic signatures over the client's input message msg.

The RECOMMENDED variants are RSAPBSSA-SHA384-PSS-Randomized or RSAPBSSA-SHA384-PSSZERO-Randomized. See for discussion about interoperability considerations and deterministic signatures.

Security Considerations Amjad et al. proved the following properties of RSAPBSSA:

• One-more-unforgeability: For any adversary interacting with the server (i.e., the signer) as a client that interacts with the server at most n times is unable to output n+1 valid message and signature tuples (i.e., the signature verifies for the corresponding message). This holds for any n that is polynomial in the security parameter of the scheme.
• Concurrent one-more-unforgeability: The above holds even in the setting when an adversarial client is interacting with multiple servers (signers) simultaneously.
• Unlinkability: Consider any adversary acting as the server (signer) interacting with n clients using the same public metadata. Afterwards, the adversary randomly receives one of the n resulting signatures as a challenge. Then, the adversary cannot guess which of the n interactions created the challenge signature better than a random guess.

The first two unforgeability properties rely on the Strong RSA Known Target Inversion Problem. This is slightly stronger assumption that the RSA Known Target Inversion Problem used in RSABSSA. In the RSA Known Target Inversion Problem, the challenger is given a fixed public exponent e with the goal of computing the e-th root of n+1 random elements while using an e-th oracle at most n times. In comparison, the Strong RSA Known Target Inversion Problem enables the challenger to choose any public exponents e_1,...,e_n+1 > 1 such that it can be the e_i-th root for the i-th random element. One can view the difference between the Strong RSA Known Target Inversion and RSA Known Target Inversion problems identical to the differences between the Strong RSA and RSA problems. The final property of unlinkability relies only on the fact that the underlying hash functions are modelled as random oracles. All the security considerations of RSABSSA in also apply to RSAPBSSA here. We present additional security considerations specific to RSAPBSSA below.

Strong RSA Modulus Key Generation An essential component of RSAPBSSA is that the KeyGen algorithm in generates a RSA modulus that is the product of two strong primes. This is essential to ensure that the resulting outputs of DerivePublicKey in does cause errors in DeriveKeyPair in . We note that an error in DeriveKeyPair would incur if the output of DerivePublicKey does not have an inverse modulo phi. By choosing the RSA modulus as the product of two strong primes, we guarantee the output of DerivePublicKey will never incur errors in DeriveKeyPair. It is integral that one uses the KeyGen algorithm for RSAPBSSA instead of the standard RSA key generation algorithms (such as those used in ). If one uses standard RSA key generation, there are no guarantees provided for the success of the DeriveKeyPair function and, thus, being able to correctly sign messages for certain choices of public metadata.

Domain Separation for Public Key Augmentation The purpose of domain separation is to guarantee that the security analysis of any cryptographic protocol remain true even if multiple instances of the protocol or multiple hash functions in a single instance of the protocol are instantiated based on one underlying hash function. The DerivePublicKey in of this document already provide domain separation by using the RSA modulus as input to the underlying HKDF as the info argument. As each instance of RSAPBSSA will have a different RSA modulus, this effectively ensures that the outputs of the underlying hash functions for multiple instances will be different even for the same input. Additionally, the hash function invocation used for computing the message digest is domain separated from the hash function invocation used for augmenting the public key in DerivePublicKey. This domain separation is done by prepending the inputs to each hash function with a unique domain separation tag.

Choosing Public Metadata The unlinkability property of RSAPBSSA guarantees anonymity for any signature amongst the set of all interactions with the server (signer) with the same choice of public metadata. In other words, the server is unable to identify the interaction that created the signature. The unlinkability guarantee of RSAPBSSA is only useful when there are a significant number of server (signer) interactions for any value of public metadata. In the extreme case where each server interaction is performed with a different value of public metadata, then the server can uniquely identify the server interaction that created the given signature. Applications that use RSAPBSSA MUST guarantee that the choice of public metadata is limited such that there is a significant number of server (signer) interactions across many clients for any individual value of public metadata that is signed. This should be contextualized to an application's user population size.

Denial of Service RSAPBSSA is suspectible to Denial of Service (DoS) attacks due to the flexibility of choosing public metadata used in DerivePublicKey in . In particular, an attacker can pick public metadata such that the output of DerivePublicKey is very large, leading to more computational cost when verifying signatures. Thus, if attackers can force verification with metadata of their choosing, DoS attacks are possible. For applications where the values of potential public metadata choices are fixed ahead of time, it is possible to try and mitigate DoS attacks. If the set of possible metadata choices is small, then applications SHOULD use one of the protocol variants in with distinct keys for each metadata value.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK] Informative References Fastly Inc. Apple Inc. Cloudflare This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-wood-cfrg-blind-signatures. Brave Software Brave Software Google LLC Cloudflare This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

Acknowledgments The authors would like to thank Nikita Borisov for pointing out an issue with a prior attempt at mitigating DoS attacks.

Test Vectors This section includes test vectors for the RSAPBSSA-SHA384-PSS-Randomized variant defined in . The following parameters are specified for each test vector:

• p, q, d, e, N: RSA private and public key parameters, each encoded as a hexadecimal string.
• msg: Input messsage being signed, encoded as a hexadecimal string. The hash is computed using SHA-384.
• info: Public metadata bound to the signature, encoded as a hexadecimal string.
• eprime: The augmented public key exponent corresponding to e and metadata, encoded as a hexadecimal string.
• blind: The message blinding value, encoded as a hexadecimal string.
• salt: Randomly-generated salt used when computing the signature. The length is 48 bytes.
• blinded_msg, blinded_sig: The protocol values exchanged during the computation, encoded as hexadecimal strings.
• sig: The output message signature.