]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

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

Introduction This document specifies an attribute for attestation to the possession of a private key. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject has possession of the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept an attestation from the subject instead of proof of possession. offers some algorithms to provide proof of possession for Diffie-Hellman private keys. However, these algorithms are not suitable for use with PKCS#10 . On the other hand, the attestation attribute specified in this document is suitable for use with PKCS#10. More and more, a subject needs two certificates, one for digiatal signatures, and a separate one for key establishment. 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. In this situation, a CA might accept an attestation that can be validated with the previously issued signature certificate might be adequate for subsequent issuance of the key establishment certificate. When using the attribute for attestation to the possession of the key establishment private key, the process for a subject to obtain two certificates 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.
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 attestation attribute that is specified in of this document. The subject name matches the one from step 2, and it 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.

ASN.1 The attestation attribute 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 Attestation to the Possession of a Private Key The attribute for attestation to the possession of a private key is included in a certificate request to attest that the subject of the signature certificate that is used to validate the signature on the certificate request also has possession of the private key that corresponds to the public key in the restificate request. The subject in the signature certificate MUST be the same as the subject name in the certificate request. If they are different, the CA MUST reject the certificate request. If subject alternative names are present in the certificate request, they MUST match subject alternative names in the signature certificate. If the certificate request contains subject alternative names that are not present in the signature certificate, the CA MUST reject the certificate request. The attribute for attestation to the possession of a private key has the following structure: The components of the PrivateKeyAttest SEQUENCE have the following semantics:

• serialNumber:

  the serial number of the signature certificate.

• issuer:

  the issuer name of 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 is omitted.

• keyIdentifier:

  the key identifier for the public key in 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 is omitted.

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

• certificationRequestInfo:

  the subject name MUST 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 privateKeyAttest 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.

Conventions for CRMF This section specifies the conventions for using the attribute for attestation to the possession of a private key with the Certificate Request Message Format (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 MUST match the subject name in the signature certificate, and the 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 MUST 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, and signature over the poposkInput MUST validate with the public key in the signature certificate.

• regInfo:

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

Security Considerations The subject is signing an attestation that is has possession of the key establishment private key instead of providing some other form of proof. If the subject has lost control of the signature private key, then the attestation could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control. 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 attestation is not the weak part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair.

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 "id-mod-private-key-attest-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).

Acknowledgements Thanks to Sean Turner and Joe Mandel for their constructive comments.

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. 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 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 . PrivateKeyAttest-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-private-key-attest-2025(TBD0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS ATTRIBUTE FROM PKIX-CommonTypes-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } CertificateSerialNumber, Name, id-pkix FROM PKIX1Explicit-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } KeyIdentifier FROM PKIX1Implicit-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } ; -- -- Private Key Attestation Attribute -- id-at-privateKeyAttest OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 22112 2 1 } privateKeyAttest ATTRIBUTE ::= { TYPE PrivateKeyAttest IDENTIFIED BY id-at-privateKeyAttest } PrivateKeyAttest ::= SEQUENCE { serialNumber CertificateSerialNumber, issuer [0] Name OPTIONAL, keyIdentifier [1] KeyIdentifier OPTIONAL } -- -- Registration Control Support -- RegControlSet ATTRIBUTE ::= { regCtrl-privateKeyAttest, ... } regCtrl-privateKeyAttest ATTRIBUTE ::= privateKeyAttest id-regCtrl-privateKeyAttest OBJECT IDENTIFIER ::= id-at-privateKeyAttest END ]]>