An Attribute for Statement of Possession of a Private Key
Extracted elements (19)
RFC 6955 provides proof-of-possession algorithms for Diffie-Hellman private keys but is not suitable for use with PKCS#10 and does not support key encapsulation mechanism (KEM) algorithms such as ML-KEM. This attribute is designed to fill that gap, working with both PKCS#10 and CRMF and supporting modern post-quantum KEM algorithms.
The `cert` field in `PrivateKeyPossessionStatement` is OPTIONAL: when the issuer of the key establishment certificate is the same as the issuer of the signature certificate, including the full certificate is unnecessary because the CA is assumed to have access to all valid certificates it has issued.
This attribute is defined to be usable with both PKCS#10 (RFC 2986) certificate requests and CRMF (RFC 4211) certificate request messages, with separate convention sections (4 and 5) specifying the required structure for each format.
For CRMF use: the `popo` field MUST use the signature CHOICE, `poposkInput` MUST be present, `POPOSigningKeyInput.authInfo` MUST use the sender CHOICE, `publicKey` MUST be a copy of the key from `certTemplate`, and the signature MUST validate with the public key in the signature certificate.
For CRMF use: the `regInfo` attributes MUST include the `privateKeyPossessionStatement` attribute as specified in Section 3.
For PKCS#10 use: the `subjectPKInfo` in `certificationRequestInfo` MUST contain the public key for the key establishment algorithm, and the attributes MUST include the `privateKeyPossessionStatement` attribute. The `signatureAlgorithm` MUST be one that can be validated with the public key in the signature certificate.
If the issuers of the signature certificate and the key establishment certificate will be different, the certificate policy of the issuer of the key establishment certificate MUST explain the procedure used to verify the subject and subject alternative names.
Subject alternative names present in the certificate request SHOULD match those in the signature certificate. If they differ, the certificate policy MUST describe how to determine they identify the same entity; otherwise the CA MUST reject the request.
The CA MUST perform certification path validation for the signature certificate as specified in Section 6 of RFC 5280. If the certification path is not valid, the CA MUST reject the request for the key establishment certificate.
The CA MUST validate the signature on the certificate request using the public key from the signature certificate. If the signature is not valid, 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 differ, the certificate policy MUST describe how the CA determines the two subject names identify the same entity; if the CA cannot make that determination, it MUST reject the request.
For CRMF use, the document defines `regCtrl-privateKeyPossessionStatement` and `id-regCtrl-statementOfPossession` as aliases to the attribute and OID defined in Section 3, following CRMF Registration Control naming conventions from RFC 4211.
The `privateKeyPossessionStatement` attribute (OID 1.3.6.1.4.1.22112.2.1) is an ASN.1 ATTRIBUTE typed as `PrivateKeyPossessionStatement`, included in a certificate request to assert that the subject has possession of the private key corresponding to the requested public key, without providing technical proof.
IANA has assigned OID 118 with description "id-mod-private-key-possession-stmt-2025" in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0) for the ASN.1 module defined in Appendix A.
If a CA revokes a compromised signature certificate, it SHOULD also revoke all key establishment certificates that were obtained with `privateKeyPossessionStatement` attributes signed by that compromised signature certificate.
If the subject has lost control of the signature private key, the signed `privateKeyPossessionStatement` attribute could be forged by another party. Timely revocation of the compromised signature certificate is the only protection against this threat.
The `privateKeyPossessionStatement` attribute MUST NOT be used to obtain a signature certificate. Proof of possession of the signature private key is already accomplished by signing the certificate request itself.
The signature key pair SHOULD be at least as strong as the key establishment key pair, so that the signature on the statement is not the weakest link in the certificate enrollment process.
`PrivateKeyPossessionStatement` is an ASN.1 SEQUENCE with two fields: `signer` (IssuerAndSerialNumber, identifying the signature certificate) and `cert` (Certificate, OPTIONAL — the signature certificate itself, which MAY be omitted when the issuer is the same for both certificates).