]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

Security Internet-Draft This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.

Introduction This document specifies an attribute for a statement of possession of a private key by a certificate subject. X.509 certificate enrollment often depends on PKCS#10 or the Certificate Request Message Format (CRMF) . As part of enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. Alternatively, a CA may accept a signed statement from the certificate subject claiming knowledge of that private key. When a certificate subject needs separate certificates for signature and key establishment, a signed statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. For example, a subject may need a signature certificate that contains a ML-DSA public key and a key establishment certificate that contains a ML-KEM public key. For another example, a subject may need a signature certificate that contains a ECDSA public key and a key establishment certificate that contains a ECDH public key. A statement of possession may be used in lieu of the usual proof of possession mechanisms. The statement is simply a signed assertion that the requestor of a key establishment certificate has possession of the key establishment private key, and that statement is signed using a signature private key that was previously shown to be in the possession of the same certificate subject. If the Certificate Policy allows, the CA MAY accept this statement in lieu of proof that the requestor has possession of the private key. Note that offers some algorithms that provide proof of possession for Diffie-Hellman private keys; however, these algorithms are not suitable for use with PKCS#10 . In addition, the algorithms in do not support key encapsulation mechanism algorithms, such as ML-KEM. The attribute specified in this document, on the other hand, is suitable for use with both PKCS#10 and the CRMF . When using the attribute defined in this document to make a statement about the possession of the key establishment private key, the process to obtain two certificates with PKCS#10 is:

1. The subject generates the signature key pair.
2. The subject composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner. It includes a signature that is produced with the private key from step 1.
3. The subject sends the CSR to the CA, and it gets back a signature certificate. The signature certificate includes a key usage of digitalSignature, nonRepudiation, or both .
4. The subject generates the key establishment key pair.
5. The subject composes a PKCS#10 CSR containing the key establishment public key. The CSR attributes include the attribute specified in of this document. The subject name matches the one from step 3. The CSR includes a signature that is produced with the private key from step 1.
6. The subject sends the CSR to the CA, and it gets back a key establishment certificate. The key establishment certificate includes a key usage of keyEncipherment or keyAgreement .

ASN.1 The attribute defined in this document is generated using ASN.1 , using the Distinguished Encoding Rules (DER) .

Terminology 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.

Attribute for Statement of Possession of a Private Key The attribute for statement of possession of a private key is included in a certificate request to make the following statement:

• "The subject of the signature certificate that is used to validate the signature on this certificate request states, without providing proof, that it has possession of the private key that corresponds to the public key in the certificate request."

The CA MUST perform certification path validation for the signature certificate as specified in . If the certification path is not valid, then the CA MUST reject the certificate request. The CA MUST validate the signature on the certificate request using the public key from the signature certificate. If the signature is not valid, then the CA MUST reject the certificate request. The subject in the signature certificate SHOULD be the same as the subject name in the certificate request. If they are different, the certificate policy MUST describe how the CA can determine that the two subject names identify the same entity. If the CA is unable to determine that the two subject names identify the same entity, then the CA MUST reject the certificate request. If subject alternative names are present in the certificate request, they SHOULD match subject alternative names in the signature certificate. If the CA is unable to determine that each of subject alternative names identifies the same entity as is named in the signature certificate, then the CA MUST reject the certificate request. The attribute for statement of possession of a private key has the following structure: The components of the PrivateKeyStatement SEQUENCE have the following semantics:

• signer:

  the issuer name and certificate serial number of the signature certificate.

• cert:

  the signature certificate. If the issuer of the key establishment certificate will be the same as the issuer of the signature certificate, then this component MAY be omitted. When the signature certificate is omitted, the signer is assuming that the CA has a mechanism to obtain all valid certificates that it issued.

Conventions for PKCS#10 This section specifies the conventions for using the attribute for statement of possession of a private key with PKCS#10 when requesting a key establishment certificate. The PKCS#10 CertificationRequest always has three components, as follows:

• certificationRequestInfo:

  the subject name SHOULD be the same as the subject name in the signature certificate, the subjectPKInfo MUST contain the public key for the key establishment algorithm, and the attributes MUST include privateKeyPossessionStatement attribute as specified in of this document.

• signatureAlgorithm:

  the signature algorithm MUST be one that can be validated with the public key in the signature certificate.

• signature:

  the signature over certificationRequestInfo MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in .

Conventions for CRMF This section specifies the conventions for using the attribute for statement of possession of a private key with the CRMF when requesting a key establisment certificate. The following ASN.1 types are defined for use with CRMF. They have exactly the same semantics and syntax as the attribute discussed above, but they offer a similar naming convention to the Registration Controls in . The CRMF CertificationRequest always has three components, as follows:

• certReq:

  the certTemplate MUST include the subject and the publicKey components. The same subject name SHOULD match the subject name in the signature certificate, and publicKey MUST contain the public key for the key establishment algorithm.

• popo:

  the ProofOfPossession MUST use the signature CHOICE, the poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use the sender CHOICE, the sender SHOULD be set to the subject name that appears in the signature certificate, the publicKey MUST contain a copy of the public key from the certTemplate, the algorithmIdentifier MUST identify a signture algorithm that can be validated with the public key in the signature certificate, signature over the poposkInput MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in .

• regInfo:

  the attributes MUST include privateKeyPossessionStatement attribute as specified in of this document.

Security Considerations The privateKeyPossessionStatement attribute MUST NOT be used to obtain a signature certificate. Performing proof of possession of the signature private key is easily accomplished by signing the certificate request. The subject is signing privateKeyPossessionStatement attribute to tell the CA that it has possession of the key establishment private key. This is being done instead of providing technical proof of possession. If the subject has lost control of the signature private key, then the signed privateKeyPossessionStatement attribute could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control. If the CA revokes a compromised signature certificate, then the CA SHOULD also revoke all key establishment certificates that were obtained with privateKeyPossessionStatement attributes signed by that compromised signature certificate. The signature key pair and the key establishment key pair are expected to have roughly the same security strength. To ensure that the signature on the statement is not the weakest part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair. If a CA allows subject in the key establishment certificate to be different than the subject name in the signature certificate, then certificate policy MUST describe how to determine that the two subject names identify the same entity. Likewise, if a CA allows subject alternative names in the key establishment certificate that are not present in the signature certificate, then certificate policy MUST describe how to determine that the subject alternative names identify the same entity as is named in the signature certificate.

IANA Considerations For the ASN.1 Module in the of this document, IANA is requested to assign an object identifier (OID) for the module identifier (TBD0) with a Description of "d-mod-private-key-possession-stmt-2025". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

References Normative References This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] 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] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. ITU-T ITU-T 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. Informative References This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm. This document obsoletes RFC 2875.

ASN.1 Module This ASN.1 Module builds upon the conventions established in .

Example use of the privateKeyPossessionStatement Attribute In this example, the self-signed certificate for the CA is: Alice generates her ECDSA signature key pair. Then, Alice composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner as specified in . The CSR includes a signature that is produced with her ECDSA private key. The CSR is: The CA issues a signature certificate to Alice: Alice generates her ECDH key establishment key pair. Then, Alice composes a PKCS#10 CSR. The CSR attributes include the privateKeyPossessionStatement attribute, which points to her ECDSA signature certificate. The CSR includes her ECDH public key and a signature that is produced with her ECDSA private key. The CSR is: The CSR decodes to: The CA issues a key establishment certificate to Alice:

Acknowledgements Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, and Deb Cooley for their constructive comments.