An Attribute for Attestation to the Possession of a Private Key

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 July 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document specifies an attribute for attestation to the possession of a private key. As part of X.509 certificate [RFC5280] 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. [RFC6955] offers some algorithms to provide proof of possession for Diffie-Hellman private keys. However, these algorithms are not suitable for use with PKCS#10 [RFC2986]. 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 Section 2 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.¶

2. 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:¶

   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 }

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

3. 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 [RFC2986] 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 Section 2 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.¶

4. 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) [RFC4211] 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 [RFC4211].¶

  regCtrl-privateKeyAttest ATTRIBUTE ::= privateKeyAttest

  id-regCtrl-privateKeyAttest OBJECT IDENTIFIER ::=
    id-at-privateKeyAttest

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 Section 2 of this document.¶

5. 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.¶

6. IANA Considerations

For the ASN.1 Module in the Appendix A 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).¶

7. Acknowledgements

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

8. References

Appendix A. ASN.1 Module

This ASN.1 Module builds upon the conventions established in [RFC5912].¶

<CODE STARTS>

 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

<CODE ENDS>

Author's Address