Summary

  • RFC 9883 lets a previously certified signature key carry a private-key possession statement for a different key-establishment request.
  • The statement asserts possession; it does not technically prove possession of the new private key.
  • The CA must validate the signer’s certification path and the request signature, apply identity-equivalence policy, and refuse use of the attribute for a signature certificate.

The operational trap is easy to miss: a successful signature check answers “who signed this request?” It does not answer “who controls the private key named in the requested certificate?” The privateKeyPossessionStatement attribute moves assurance from the first key to the second one, but only as a signed claim.

The attribute has OID 1.3.6.1.4.1.22112.2.1. Its complete value is PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: signer identifies the signature certificate by issuer name and serial number, while optional cert carries that signature certificate. The certificate can be omitted only when the CA is also the issuer of that signature certificate and can retrieve all valid certificates it issued. This is a narrow retrieval exception, not permission to guess the signer’s identity.

Before accepting the request, the CA must validate the certification path for the signature certificate and reject an invalid path. It must also validate the request signature with that certificate’s public key and reject a failed signature check. Subject and subject alternative names should match those in the signature certificate. If they differ, certificate policy must explain the equivalence; where the CA cannot establish it, the request must be rejected. The attribute must not be used to obtain a signature certificate. The intended target is a key-establishment certificate.

The wire placement differs by request format. In PKCS#10, subjectPublicKeyInfo carries the key-establishment public key, the attributes carry the possession statement, and the request’s signature is checked with the signature certificate. In CRMF, the certificate request carries the subject and key-establishment public key; proof-of-possession uses the signature choice and sender identity, while regInfo carries the possession statement. These formats are not interchangeable containers merely because both can express the same enrollment idea.

RFC 5280 supplies the certification-path and key-usage baseline. RFC 6955 is a useful contrast because it describes technical proof-of-possession mechanisms for Diffie-Hellman keys. That contrast defines the boundary: RFC 9883 does not turn its attribute into a cryptographic proof of the second private key. This control surface is also distinct from RFC 9881’s ML-DSA identifiers in PKIX and RFC 9882’s CMS signed-byte rules.

Theo March analysis: this is an assurance-transfer design. Treating the signature certificate as a delegated assurance root is an operational interpretation, not an RFC mandate. A CA should correlate every derived key-establishment certificate with the authorizing signature certificate in audit records, record the identity-equivalence decision, and monitor repeated statements, unusual subject changes, and signer-to-request volume. Those controls make the transfer inspectable rather than invisible.

The transfer also creates revocation fan-out. RFC 9883 says that timely revocation is the only protection identified when the signature certificate is compromised, and says the CA should revoke key-establishment certificates obtained through statements signed by that compromised certificate. A fan-out inventory, alerting, and sequencing policy are Theo March analysis, not a prescribed automation schema. Strength parity matters too: the signature key should provide security strength at least equal to the key-establishment key.

During migration, a CA should block weaker authorizers, test algorithm transitions, and require an explicit equivalence policy rather than silently broadening identity.

Enrollment fixtures should include: a valid path and valid request signature; an invalid signer path; a changed request signature; a missing embedded certificate where the CA is not the issuer; an omitted certificate where issuer retrieval succeeds; mismatched subject names; mismatched SANs with documented equivalence; mismatched SANs without equivalence; an attempt to issue a signature certificate; a weaker signature key; and separate PKCS#10 and CRMF encodings checked at their format-specific locations. Audit output should link signer issuer/serial, request fingerprint, target key fingerprint, policy decision, and resulting certificate.

Incident path: first stop issuance from the suspect signature certificate and preserve requests and validation evidence. Validate whether compromise is confirmed, revoke the signature certificate promptly, identify every derived certificate authorized by its statements, and assess or revoke that population according to the CA’s response policy. Then rotate both roles where necessary, review identity-equivalence decisions and strength-parity exceptions, and monitor for replay or new statements. This response path is analysis for operating the dependency; RFC 9883 supplies the revocation consequence, not a complete incident workflow.

Sources