v0.8.0

This release adds central key generation (RFC 9483 section 4.1.6): the CA generates the key pair and sends the private key signed and encrypted for the device. A client can also act as a registration authority, use implicit confirmation, resume a waiting enrollment in a later process and revoke a certificate by issuer and serial number. It also limits the work a peer can force on a verifier with large RSA keys or PBMAC1 parameters. Before upgrading, read the entries on the MAC iteration minimum and the per-credential transaction quota.

client

• Central key generation. SendIRWithCentralKeyGeneration, SendCRWithCentralKeyGeneration and SendKURWithCentralKeyGeneration ask the CA to generate the key pair. EnrollResult.GeneratedKey holds the private key. The client verifies its signature and checks it against the issued certificate. The CA encrypts the key to the MAC shared secret or to an RSA or ECDSA protection key.
• WithRegistrationAuthority sends every request of an operation in a nested message signed with the RA credentials (RFC 9483 section 5.2.2.1). The OpenSSL 4.1 mock server does not accept nested messages.
• WithImplicitConfirm asks the CA for implicit confirmation. When the CA grants it, EnrollResult.ImplicitConfirm is set and no certConf is sent. The client now also honors a grant it did not ask for. It used to send a certConf that the CA refused.
• WithDeferredPolling returns at the first waiting answer with EnrollResult.Pending set. ResumeEnrollment continues from that state later, also in another process. Polling that stops before the CA decides now returns a PendingError that resumes the same way. errors.Is still finds the context error in it.
• SendRRBySerial revokes a certificate by issuer and serial number without a copy of it. WithInvalidityDate adds an invalidityDate to a revocation request.
• New request options set the certReqId (WithCertReqID), extra generalInfo items (WithGeneralInfo), the proof-of-possession digest (WithPOPHash) and a requested validity (WithTemplateValidity), which the CA may ignore.
• The default HTTP client times out an exchange after 120 seconds (DefaultHTTPTimeout). WithHTTPClient replaces the client and its timeout.
• Test aids WithCertConfStatus, WithMessageMutator and WithProtectedMessageMutator send messages that break RFC 9483 to check how a CA handles them. Do not use them in production.

server

• WithCentralKeyGeneration generates the key pair with a KeyGenerator you provide and signs the private key with a key generation authority. The default format is the one OpenSSL clients read. WithCentralKeyGenerationAsymmetricKeyPackage and WithCentralKeyGenerationAESKeyWrap select the RFC 9810 and RFC 9481 formats. The CA gets the public key from GeneratedPublicKeyFromContext.
• WithUnprotectedErrorsBeforeAuthentication sends errors raised before the sender is authenticated without protection, as RFC 9483 section 3.6.4 allows. Use it with a slow signer such as SLH-DSA, which otherwise signs an error for every unauthenticated request.
• The per-credential quota follows the shared secret. Transactions and WithMaxTransactionsPerCredential of MAC-protected clients are keyed by the shared secret instead of the sender name, which a client could change to get a fresh quota. Clients that share a secret share a quota. MAC transactions in a snapshot from an earlier version cannot be resumed.
• A late certConf after the confirmWaitTime is refused with badRequest and the CertificateConfirmer hears ConfirmExpired. It used to be accepted until CleanupExpired ran.
• WithStrictProfileValidation refuses a pollReq or popdecr that repeats the senderNonce of the last request or response in the transaction.
• WithAnyCertReqID accepts a certReqId other than 0. RevocationRequest.InvalidityDate passes the requested invalidityDate to the Revoker.
• The statusString of a refused protection or recipient holds only the reason, such as message not protected, without the Go error text.

pkicmp

• Central key generation helpers, such as NewKeyPackage, ParseKeyPackage and CertTemplate.RequestsCentralKeyGeneration.
• NewRevDetailsBySerial and NewInvalidityDateExtension build revocations by serial number and with an invalidityDate.
• CertTemplate.Validity reads and writes a requested validity. A malformed validity now fails parsing.
• SignatureCredentials.WithHash and CertReqMsg.GeneratePOPWithHash choose the signature digest.
• RSA keys above 16384 bits are refused with ErrRSAKeyTooLarge wherever a peer supplies one.
• DefaultMinMACIterationCount is 100, as RFC 4211 requires, instead of 1. A MAC with fewer iterations is refused unless WithMACIterationLimits lowers the minimum. NewMACCredentials needs the same option to send fewer.
• PBMAC1 limits cover the whole key derivation, iterations times PRF output blocks. DefaultMaxMACIterationCount is 1000000 units of that work, enough for the Siemens CMP test suite.
• Trailing bytes inside the extraCerts wrapper now fail parsing with a ParseError.

cms

• EncryptSignedData encrypts a SignedData for one recipient. Password and PWRIKEKPassword encrypt for a shared secret with the RFC 9481 or the RFC 3211 key wrap. Decrypt opens both.

examples/mockserver

• The mock CA generates key pairs for central key generation and accepts registration authorities. The example command enables both. It also publishes the invalidityDate of a revocation in the CRL entry.
• The mock CA certifies ML-KEM-768 and ML-KEM-1024 keys that prove possession by decryption. It used to fail to sign them.

v0.7.2

This release lets a client keep the CA certificates in caPubs from becoming trust anchors and requires Go 1.27.3, which fixes GO-2026-6809 in crypto/x509.

client

• WithoutCAPubsTrust keeps the CA certificates in caPubs of a MAC-protected response from extending WithTrustedCAs, so the issued certificate must chain to the configured trusted CAs. Use it when the anchors are known out of band. Without the option caPubs are still trusted, as RFC 9810 section 5.3.2 allows. EnrollResult.CAPubs still holds them.

Requirements

• Go 1.27.3 or newer is required. Go 1.27.2 has GO-2026-6809 in crypto/x509, which the client and server reach when they verify certificate chains.

v0.7.1

This release fixes how the server answers faulty requests. A senderKID that names another key is refused, a malformed request gets an error message with badDataFormat and a reused transaction ID gets transactionIdInUse. The first and last fixes matter most to hosts whose certificate lookup ignores senderKID or that restore stored transactions into a server with small limits.

pkicmp

• infoValue in genm, genp and generalInfo items must be one DER element. A value that is not valid ASN.1 or carries trailing data now fails parsing with a ParseError. Before, it was kept as raw bytes.
• ParseError.Header holds the message header when parsing failed after a readable header, so a receiver can still answer the sender.

server

• senderKID check. A signed request whose senderKID does not match the subject key identifier of the certificate that verifies it is refused with badMessageCheck, as RFC 9483 section 3.5 requires. Before, a CertificateLookup that ignored senderKID let such a request through. A certificate without a subject key identifier is not compared.
• Malformed requests whose header can be read get an error message with badDataFormat over HTTP 200. Before, a malformed infoValue in a genm got a genp. A malformed ir, cr or kur body or malformed template extensions got systemFailure. A malformed protection or extraCerts field or trailing data got HTTP 400. Input without a readable header still gets HTTP 400. That now includes a request whose generalInfo holds a malformed infoValue, which was processed before.
• transactionIdInUse answers a first message that reuses the transaction ID of a transaction the server still holds, also when a transaction limit is full. Before, a full limit answered systemUnavail with "maximum transaction limit reached".

v0.7.0

This release adds SLH-DSA keys (FIPS 205, RFC 9909) for all twelve parameter sets. Devices can enroll SLH-DSA keys with ir, cr, kur and p10cr and protect CMP messages with them. A CA can hold an SLH-DSA key, sign the CMP responses with it and have clients verify its certificates. It works with OpenSSL 3.5 and later in both directions and with EJBCA 9.6.3. The library now depends on github.com/cloudflare/circl for SLH-DSA.

pkicmp

• SLH-DSA keys. ParsePublicKey returns an SLH-DSA key as an slhdsa.PublicKey value from github.com/cloudflare/circl/sign/slhdsa. MarshalPublicKey, PublicKeysEqual, GeneratePOP, VerifyPOP, NewSignatureCredentials and Verify support SLH-DSA keys and signatures. Signatures use the pure mode with an empty context. The pre-hash variant HashSLH-DSA is refused. SLHDSAAlgorithmOID and SLHDSAAlgorithmFromOID map parameter sets to their identifiers.
• CheckCertificateRequestSignature checks the self-signature of a PKCS #10 request, SLH-DSA requests included, which crypto/x509 cannot check.
• NewCertStatus confirms a certificate signed by an SLH-DSA CA with SHA-512 and names it in hashAlg, as for ML-DSA. Verify checks protection certificates issued by an SLH-DSA CA and RootCAKeyUpdate.Verify checks SLH-DSA root certificates.

client

• SendIR, SendCR, SendKUR and SendP10CR accept SLH-DSA keys and requests. NewSignatureCredentials with an SLH-DSA key protects requests with SLH-DSA signatures.
• The client trusts certificates and responses from a CA with an SLH-DSA key when that CA certificate is in the trust pool and travels in the response.

server

• The server checks SLH-DSA proofs of possession, PKCS #10 requests and message protection. The CA receives an SLH-DSA key in the template as slhdsa.PublicKey. crypto/x509 cannot certify it, so the CA encodes the SubjectPublicKeyInfo with pkicmp.MarshalPublicKey and signs the certificate itself. Its key usage must not allow encipherment.
• WithSigner accepts an SLH-DSA CA key. WithStrictProfileValidation checks extraCerts chains that an SLH-DSA CA signed. Each SLH-DSA signature is slow, so a separate classical or ML-DSA signer keeps the responses fast.

Requirements

• github.com/cloudflare/circl v1.6.5 is now required for SLH-DSA. It brings in golang.org/x/sys v0.49.0.

v0.6.0

This release enrolls keys that cannot sign, such as ML-KEM-768 and ML-KEM-1024, through proof of possession by decryption: the encrypted certificate and challenge-response methods of RFC 9810. It works against EJBCA, with OpenSSL 3.0 and later for RSA keys and with OpenSSL 4.0 for ML-KEM keys. CAs can hold enrollment and revocation requests until someone approves or rejects them. They can also answer grantedWithMods. Some refusal reasons and the handling of waiting requests changed. Code that checks refusal reasons or relies on waiting requests should read the pkicmp and server entries before upgrading.

The new documentation site at misiektoja.github.io/go-pki-cmp has client and server guides, option references, troubleshooting and the list of tested CMP implementations.

pkicmp

• Proof of possession by decryption. NewKeyAgreementPOP joins NewKeyEnciphermentPOP. Both take SubsequentMessageEncrCert or SubsequentMessageChallengeResp. NewEncryptedCertificate carries an encrypted certificate in EnvelopedData and NewEncryptedValueCertificate in the EncryptedValue of CMP version 2. CertOrEncCert.EncryptedCertificate and EncryptedValueCertificate read them. NewPopDecCBody, NewPopDecRBody, PKIBody.PopDecC, PKIBody.PopDecR, ChallengeWitness, Challenge.VerifyWitness, Rand and ParseRand build and check the challenge and its answer.
• ML-KEM public keys. ParsePublicKey returns ML-KEM-768 and ML-KEM-1024 keys and refuses ML-KEM-512 with ErrMLKEM512. MarshalPublicKey, IsKEMKey, PublicKeysEqual and certificate requests support them.
• Refusal reasons are more precise. ReasonUntrustedSigner reports a protection certificate that does not chain to the trusted CAs, which used to fail with ReasonSignatureFailed. ReasonSenderKIDMismatch reports a senderKID that names none of the candidate certificates, which used to fail with ReasonNoCandidateSigner. That reason now means no certificate was available. A response that carries CA certificates without a senderKID, as Nokia NCM sends them, now reports the failure of the certificate with the sender's name instead of ReasonSenderMismatch, which now means no candidate has that name.
• VerifyOptions.AllowSenderKIDMismatch tries every candidate when the senderKID names none of them, for CAs that copy the senderKID of the request. Each candidate must still chain to the trusted CAs, have the sender's name and verify the signature.
• VerifyOptions.CurrentTime checks the protection certificate and its chain at a chosen time, such as when a recorded message was received. Do not take that time from the message when the result decides whether to act on it, because the sender sets its messageTime.

client

• SendIRWithIndirectPOP, SendCRWithIndirectPOP and SendKURWithIndirectPOP enroll a key that cannot sign with EncryptedCertificate or ChallengeResponse. They accept ML-KEM-768 and ML-KEM-1024, RSA and elliptic curve keys on P-256, P-384 and P-521. They read certificates sent as EnvelopedData or as EncryptedValue and use CMP version 3 for the whole transaction. The CA must support the method. RFC 9483 lets it refuse both for a key that can sign.
• WithSenderKIDMismatch accepts signed responses whose senderKID names none of the candidate signer certificates. It is off by default.

server

• WithEncryptedCertificatePOP and WithChallengeResponsePOP accept proof of possession by decryption. Both are off by default. WithStrictProfileValidation allows them only for keys that cannot sign. An encrypted certificate never gets implicit confirmation and a certConf with the wrong hash gets badPOP. Publish the certificate only after ConfirmAccepted and revoke it on ConfirmExpired or ConfirmRejected. A challenge-response request reaches the CA only after the right answer. POPMethodFromContext tells the CA which method a request used. Keys the server cannot encrypt for, such as X25519, are refused with badAlg.
• Encrypted certificate format. A CMP version 2 request for an RSA key gets its certificate as EncryptedValue in a version 2 response, because OpenSSL 3.0 and 3.2 read only that format. Other requests get EnvelopedData in a version 3 response. WithEnvelopedDataForVersion2 sends EnvelopedData to version 2 RSA requests too, for clients that read only EnvelopedData, such as Bouncy Castle 1.86.
• Snapshots keep the proof-of-possession method and any challenge waiting for its answer. Earlier versions refuse a snapshot that holds such a challenge.
• Response.GrantedWithMods answers grantedWithMods for a CA that changed the request. Response.StatusText sets the statusString of the issued certificate. Both are off by default.
• Waiting requests end the way immediate ones do. A request that PendingChecker.CheckPending rejects gets an ip, cp or kup with its certReqId instead of an error message. The final response with a certificate grants implicit confirmation only when the request asked for it. Waiting and rejected responses no longer grant it. WaitingResponse.Reason becomes the statusString of the waiting response.
• Polling follows RFC 9483 section 4.4. An early pollReq gets another pollRep with the time left instead of failing with "polling too frequently". A pollReq must name the waiting request by its certReqId or by -1, otherwise it gets badRequest. WithOptionalPollReqRecipNonce accepts a pollReq without recipNonce, which the Insta Certifier 10 cmpclient and the Insta Certifier 7 ssh-cmpclient send. Without it they cannot collect a certificate that waited for a decision.
• WaitingError lets a Revoker or RevocationAuthorizer delay a revocation until PendingChecker.CheckPending decides. Such a revocation used to fail with systemFailure.
• WithWaitingLifetime keeps a waiting request for 24 hours after its last poll by default. Waiting requests used to expire with the confirmation wait of 10 seconds. WaitingExpirer and WithWaitingExpirer tell the CA about each waiting request that CleanupExpired removes.

cms

• New package for the EnvelopedData of proof by decryption, with RSA-OAEP, ECDH on P-256, P-384 and P-521 and ML-KEM-768 and ML-KEM-1024 recipients. Encrypt derives ML-KEM keys with HKDF-SHA256. Decrypt also accepts the KDF2, KDF3 and SHAKE256 derivations that Bouncy Castle and EJBCA use. RSA PKCS #1 v1.5 key transport is refused in EnvelopedData.
• NewEncryptedValue and DecryptEncryptedValue handle the EncryptedValue of CMP version 2 for RSA keys. Encryption uses AES-256-CBC with PKCS #1 v1.5 key transport, the only combination OpenSSL reads. Decryption also accepts AES-128, AES-192, Triple DES and RSA-OAEP and reports a padding error like any other failure.

examples/mockserver

• MockCA certifies composite ML-DSA keys. Enrolling one used to fail with systemFailure.

Requirements

• golang.org/x/crypto v0.58.0 or newer is now required.

v0.5.0

This release adds the RFC 9483 support messages. Clients can ask a CA for its CA certificates, a root CA update, a certificate request template and newer CRLs. Servers can answer these requests.

pkicmp

• General messages (genm and genp) are built with NewGenMBody and NewGenPBody and read with PKIBody.GenM and PKIBody.GenP. Typed helpers encode and parse CA certificates, root CA key updates, certificate request templates, CRL status lists, CRLs, the current CRL and unsupported OIDs. RootCAKeyUpdate.Verify checks that the old root certified the new one.
• NewCertProfileInfo builds the certProfile header item.

client

• Support messages: GetCACertificates, GetRootCAUpdate, GetCertReqTemplate, GetCRLUpdate and GetCurrentCRL ask the CA for information. SendGenM sends other info types. A root CA update is returned only if the current root signed the new one. A CRL update is returned only if it is newer than the CRL the caller holds. ErrInfoTypeNotSupported reports a type the CA lists as unsupported or leaves out of its answer. Nokia NCM leaves all of them out. EJBCA Community Edition rejects general messages with badRequest.
• WithCertProfile names a certificate profile in the request header, for enrollment or for GetCertReqTemplate.

server

• Support messages are answered by the optional CACertificatesProvider, RootCAUpdateProvider, CertReqTemplateProvider and CRLProvider interfaces. The server lists every requested type without a provider as unsupported. It refuses a root CA update that lacks a valid newWithOld certificate with systemFailure. A custom Handler answers through Response.GeneralResponse.
• WithStrictProfileValidation requires one item per general message and no value where RFC 9483 defines none.

v0.4.0

The library is now go-pki-cmp, with a new module path. This release adds device compatibility options, configurable MAC iteration limits and exact subject preservation. It fixes same-key update confirmation and enrollment with only a subjectAltName. Clients can distinguish failed certificate confirmation from a refused request.

pkicmp

• MAC iteration limits are configurable through VerifyOptions.MinMACIterationCount, MaxMACIterationCount and WithMACIterationLimits. PasswordBasedMac and PBMAC1 defaults remain 1 to 500000. VerifyResult.ProtectionParams preserves the accepted range when echoing a peer's parameters.
• CertTemplate.RawSubject preserves the received subject DER. Marshalling uses Subject and now supports subjects built with NewDirectoryNameFromRawDER.
• VerifyPOPWithOptions supports poposkInput proofs. It checks publicKeyMAC against POPOptions.SharedSecret or the sender against POPOptions.Sender. Malformed inputs fail parsing. AllowPoposkInputVariants accepts Insta Certifier 10 cmpclient encodings. These proofs verify possession of the key but do not cover the certificate template.
• CertRequest.OldCertID reads a key update's issuer and serial number. CertID.Identifies matches them to a certificate.
• Directory names use crypto/x509 string types: PrintableString where possible and UTF8String otherwise. Unencodable values now fail marshalling instead of producing an invalid name.

client

• WithMACIterationLimits bounds MAC iterations in responses. Sending a count outside the defaults also requires pkicmp.WithMACIterationCount and wider pkicmp.WithMACIterationLimits on the credentials.
• SendKUR preserves the old certificate's subject encoding unless WithTemplateSubject overrides it. For an empty subject it also copies subjectAltName unless one is supplied. Signed requests preserve the signer's subject encoding unless WithSender overrides it.
• SAN-only requests carry a NULL-DN subject as RFC 9483 requires, instead of omitting the subject field.
• ConfirmationError carries the issued certificate when certConf fails. The CA may keep or revoke it, so retrying enrollment may issue another certificate. errors.As still exposes the underlying error.

server

• WithMACIterationLimits bounds MAC iterations in requests. Responses echo the accepted count. Out-of-range requests fail before key derivation with badMessageCheck. Rejected MAC parameters now report "MAC protection parameters not accepted".
• WithRawSubject preserves every requested subject attribute, its order and string type for CRMF and PKCS#10 requests. It is off by default. CAs must check all attributes in Subject.Names and clear RawSubject before changing Subject.
• WithOptionalCertConfRecipNonce accepts certConf without recipNonce. A supplied nonce must still match and certificate hashes are still checked.
• WithPoposkInputVariants accepts Insta Certifier 10 cmpclient proofs for ir, cr and kur. Signatures and publicKeyMACs are verified, but only message protection binds the requested names to the key holder.
• WithSignatureProtectionPOP accepts a missing CRMF proof when the message is signed with the requested key, as in Nokia ssh-cmpclient same-key updates. MAC-protected requests still need a proof.
• NULL-DN subjects with subjectAltName are accepted, including under strict validation. The CA template marks subjectAltName critical. WithOptionalSubject also accepts CRMF templates that omit the subject field. Both cases require subjectAltName.
• Revocation options accept missing reasonCode (WithOptionalRevocationReason), missing issuer (WithOptionalRevocationIssuer) or MAC protection (WithMACRevocation). An absent reason becomes unspecified. A missing issuer comes from the signer's certificate when its serial matches. Otherwise the CA must resolve the serial without an issuer and reject ambiguous matches. MAC revocation requires RevocationAuthorizer approval.
• WithStrictProfileValidation overrides the optional nonce, proof, subject and revocation rules above and rejects all poposkInput proofs. Raw subject preservation and MAC limits still apply. Strict validation now accepts extraCerts without a self-signed root, while checking chain order. CertificateLookup remains responsible for trust.
• Rejection status texts now identify unsupported protocol versions and message types.
• Same-key updates complete confirmation when certConf uses the original request's credentials. Confirmation with the newly issued certificate remains refused.
• MAC-protected responses repeat the request's senderKID, including when a server signer is configured.

Requirements

• The module path is github.com/misiektoja/go-pki-cmp. Update imports and the go.mod requirement from github.com/misiektoja/go-pkicmp-ng. Package names are unchanged. Releases through v0.3.2 use the old path.
• go-composite-mldsa v0.2.1 is now required, with fixes for key parsing and certificate signing.

v0.3.2

This version requires Go 1.27.2 and updates composite ML-DSA support to the published v0.2.0 library.

Requirements

• Go 1.27.2 or newer is required. go-composite-mldsa v0.2.0 validates composite key encodings more strictly. Valid keys retain the same encoding and algorithm support.

v0.3.1

The client can revoke certificates at CAs that sign the revocation response without attaching their certificate.

pkicmp

• ReasonNoCandidateSigner reports a signature-protected message that carries no certificate to verify it, either none at all or none matching its senderKID. Such a message previously failed with ReasonSignatureFailed, so code that checks for that reason no longer sees it in this case.

client

• WithServerCerts supplies the CMP server certificates the client knows out of band, like the -srvcert option of openssl cmp. The client tries them after the certificates in the response, so a response without extraCerts verifies. Unlike -srvcert, each must still chain to WithTrustedCAs, match the sender in the response and verify the signature. A CA certificate without the digitalSignature key usage is accepted, as it already is from extraCerts. Without the option such a response fails with ReasonNoCandidateSigner and the error names WithServerCerts.

v0.3.0

Devices can enroll composite ML-DSA keys, which pair an ML-DSA key with a classical key in one certificate, through ir, cr, kur and p10cr, and revoke those certificates with rr.

pkicmp

• Composite ML-DSA proof of possession. VerifyPOP and VerifyPOPWithOptions check a composite signature over the certificate request. The algorithm must match the requested key exactly and its parameters must be absent. CertReqMsg.PublicKey returns a composite key as *compositemldsa.PublicKey.

client

• SendIR, SendCR and SendKUR accept a composite ML-DSA key and sign the proof of possession with it. SendP10CR accepts a PKCS#10 request for a composite key made with compositex509.CreateCertificateRequest. The client checks that the issued certificate carries that key.

server

• Composite ML-DSA certificate requests reach the CA after the server verifies their proof of possession. The template carries the key as *compositemldsa.PublicKey, which the CA certifies with compositex509.CreateCertificate. Confirmation, key update and revocation work for these certificates as for classical ones.