PKI 10.4 CMC Proof of Possession

• CMC Identity proof by signing with another cert owned by the same entity. If a subscriber already possesses a signing cert, the individual can just use the signing cert to sign another CMC request (this applies to enrollment, renewal, as well as revocation requests). Upon receiving a request, CA will verify the signature (as identity proof), verify the POP, and verify whether the signer matches with the request subject before issuance. Note that when this form of identity proof is provided, the identity proof control (v1 and v2), if exists in the CMC request, will be bypassed.

  • This signing verification effectively proves the identity based on previously proven (the fact the valid signing cert exists and signs) identity.

  • uses SignerIdentifier.ISSUER_AND_SERIALNUMBER support per RFC

  • The new enrollment profile used with this method is caFullCMCUserSignedCert.cfg where cmcUserSignedSubjectNameDefault and cmcUserSignedSubjectNameConstraint are used to ensure that the resulting certificate has matching subject name as that of the signing certificate.

  • For renewal, uniqueKeyConstraint has the configuration parameter allowSameKeyRenewal to control whether same key renewal is allowed or not (revoked certs cannot be renewed); renewGracePeriodConstraint can be used to control how long before or after expiration date can a cert be renewed.

• CMC Identity Proof V2 - This control requires administrator to generate and distribute a shared secret to the subscriber before each enrollment; When the subscriber generates a certificate request, the shared secret is used to compute a witness value that the server could verify with. For efficiency, the implementation requires the identification control to be used in combination with the identity prof v2 control. By default, the SharedToken plugin that retrieves the shared secret uses subscriber’s LDAP UID. Upon receipt of the certificate request, if the CMC request is not signed by a valid subscriber certificate (as per described in the previous bullet), CA will retrieve the shared secret associated with the identification provided in the request and compute the witness value to compare with the witness value in the request. Note: It is intended to be used when the subscriber does not already have a signing cert. In the case one already has a signing cert, the above signing method could be used instead for efficiency (no need for distributing shared secrets)

  • This control effectively provides the Proof of Origin based on the secret that can only be shared between CA and the intended subscriber.

  • CMC controls added:

    • id-cmc-identityProofV2 - corresponding CMCRequest parameter e.g.:

      • identityProofV2.enable=true

      • identityProofV2.hashAlg=SHA-512

      • identityProofV2.macAlg=SHA-256-HMAC

    • id-cmc-identification - corresponding CMCRequest parameter e.g.:

      • identification.enable=true

      • identification=testUser

  • added SignerIdentifier.SUBJECT_KEY_IDENTIFIER support per RFC

    • The enrollment profile to be used with this method is caFullCMCSelfSignedCert.cfg

• CMC Encrypted POP and Decrypted POP - Since encryption-only keys cannot do the signing operation required for the proof of possession required before this release, new controls are implemented to allow that. In this release, if a signing POP is not present in the certificate request, CA will assume that it is an encryption-only key. CA will generate a challenge and encrypt it with the subscriber public key in the request. CA will then compute and place all necessary information in the request record and construct an EncryptedPOP along with a failed response with the requestId in the responseInfo control back to the client. Client can process the EncryptedPOP, decrypt and retrieve the challenge, compute the witness value and construct a DecryptedPOP requestID in the regInfo control and send back to the server. CA will then use the requestId embedded in the DecryptedPOP to find the pending request, retrieve all the POP-related info, recompute and compare/varify the witness value before issuance.

  • This control effectively provides the Proof of Possession (POP) for encryption-only keys based on the fact that only the subscriber that possesses the matching private key of the request public key can decrypt the challenge and compute the witness.

  • controls added:

    • id-cmc-encryptedPOP

    • id-cmc-decryptedPOP

    • id-cmc-responseInfo

    • id-cmc-regInfo

• CMC POP Link Witness V2 - In the case when Proof of Identity and Proof of Possession are verified, there is still no proof that the identity proven in the Proof of Identity is the same identity that owns the private key in the Proof of Possession. The POP Link Witness V2 provides such proof by making sure that a shared secret associated with an identity is used to compute a witness value which in turns is placed in the underlying (CRMF or PKCS#10) request. This release requires the identification control to be used in combination with this control so that CA can find the sharedSecret more efficiently.

  • This control effectively provides the link between the Proof of identity and the POP.

  • control added: id-cmc-popLinkWitnessV2

  • control used: id_cmc_idPOPLinkRandom

• TLS client authentication enforcement for user-signed CMC requests (enrollment & revocation), where the authenticating TLS client certificate must match that of the CMC request signing certificate. This means, for HttpClient the config file will need the following:

  • secure=true

  • clientMode=true

  • nickname=<cert nickname that matches the cmc request signer’s>