Summary

  • RFC 9883 lets a subject use an already-certified signature key to state that it possesses a separate key-establishment private key, explicitly without technically proving that possession.
  • Acceptance depends on certificate policy, a valid path and request signature, a defensible identity match and a retrievable signing certificate—not on the attribute name alone.
  • If the signing key is compromised, the dependency runs forward: the CA should identify and revoke every establishment certificate issued from statements signed by it.

The request at the certificate desk looks complete. It contains a new public key, an issuer-and-serial reference to an existing certificate and a valid signature. The word “possession” even appears in the attribute name. Yet the private key that performed the signature is not the private key corresponding to the new public key. That second key has not acted at all.

Two keys, one deliberate substitution

RFC 9883 addresses key-establishment algorithms for which ordinary request signing is unavailable or unsuitable. Its subject first generates a signature key pair, signs a conventional request and receives a signature certificate. The subject then generates a separate key-establishment pair. In a second PKCS#10 request, the new public key is placed in the request, a privateKeyPossessionStatement attribute identifies the prior signature certificate, and the second request is signed with the prior signature private key.

The standard states the result precisely: the subject of the signature certificate says, without providing proof, that it possesses the establishment private key. If certificate policy permits, a CA may accept that statement instead of a technical proof such as the Diffie-Hellman mechanisms in RFC 6955. Those mechanisms do not fit PKCS#10 and do not support KEMs such as ML-KEM; the statement works with both PKCS#10 and CRMF.

That is not a flaw hidden by formal language. It is the contract. The valid request signature proves control of the signing key for the request. It binds an accountable prior credential to an assertion about another key. It does not exercise that other key, reveal its generation boundary, or show that it remains usable after issuance.

Policy carries the missing proof

The CA still has several mandatory checks. It must validate the signature certificate's path under RFC 5280 and reject an invalid path. It must validate the request signature with the public key from that certificate. The subject name should match the name in the request. If subjects or subject alternative names differ, certificate policy must explain how the CA determines that they identify the same entity; inability to make that determination requires rejection.

The attribute contains the signature certificate's issuer and serial number and may also contain the certificate. It may be omitted when both certificates share an issuer, but omission assumes the CA can retrieve every valid certificate it issued. That is an operational claim about repository completeness at decision time. An issuer-and-serial value is a locator, not the certificate, its validated path or its historical status.

PKCS#10 and CRMF preserve the same separation through different structures. PKCS#10 puts the establishment public key and statement in certificationRequestInfo, then validates the enclosing signature with the prior certificate. CRMF uses the signature choice for ProofOfPossession, requires poposkInput and a copy of the establishment public key, and places the statement in regInfo. Neither route converts the statement into an operation by the establishment key.

RFC 9883 therefore forbids using this attribute to obtain a signature certificate. A signature-capable private key can directly prove possession by signing its request. The substitute belongs only where the new key's purpose prevents that ordinary act.

The revocation graph is part of issuance

The security consequence appears after issuance. If an attacker gains the signature private key, the attacker can produce new signed possession statements. Timely revocation of the compromised signature certificate is the specified protection. RFC 9883 further says that when the CA revokes that certificate for compromise, it should also revoke all establishment certificates obtained from statements signed by it.

That recommendation requires a durable reverse index. The CA must be able to move from one compromised signature certificate to every issuance decision that depended on it. A log saying “request signature valid” is insufficient if it cannot recover the statement, policy version, identity decision and resulting certificate IDs. The signature key should also be at least as strong as the establishment key; otherwise the assurance bridge is weaker than the asset it supports.

Sources