{"disable_confirm", OPT_DISABLE_CONFIRM, '-',
"Do not confirm newly enrolled certificate w/o requesting implicit"},
{OPT_MORE_STR, 0, 0,
- "confirmation. WARNING: This leads to behavior violating RFC 4210"},
+ "confirmation. WARNING: This leads to behavior violating RFC 9810"},
{"certout", OPT_CERTOUT, 's',
"File to save newly enrolled certificate"},
{"chainout", OPT_CHAINOUT, 's',
{OPT_MORE_STR, 0, 0,
"certificate responses (ip/cp/kup), revocation responses (rp), and PKIConf"},
{OPT_MORE_STR, 0, 0,
- "WARNING: This setting leads to behavior allowing violation of RFC 4210"},
+ "WARNING: This setting leads to behavior allowing violation of RFC 9810"},
{"no_cache_extracerts", OPT_NO_CACHE_EXTRACERTS, '-',
"Do not keep certificates received in the extraCerts CMP message field"},
{ "srvcertout", OPT_SRVCERTOUT, 's',
{OPT_MORE_STR, 0, 0,
"certificate responses (ip/cp/kup), and revocation responses (rp)."},
{OPT_MORE_STR, 0, 0,
- "WARNING: This setting leads to behavior violating RFC 4210"},
+ "WARNING: This setting leads to behavior violating RFC 9810"},
{"accept_unprotected", OPT_ACCEPT_UNPROTECTED, '-',
"Accept missing or invalid protection of requests"},
{"accept_unprot_err", OPT_ACCEPT_UNPROT_ERR, '-',
#include "cmp_local.h"
#include "internal/crmf.h"
-/* ASN.1 declarations from RFC4210 */
+/* explicit #includes not strictly needed since implied by the above: */
+#include <openssl/cmp.h>
+#include <openssl/crmf.h>
+
+/* ASN.1 declarations from RFC 9810 */
ASN1_SEQUENCE(OSSL_CMP_REVANNCONTENT) = {
/* OSSL_CMP_PKISTATUS is effectively ASN1_INTEGER so it is used directly */
ASN1_SIMPLE(OSSL_CMP_REVANNCONTENT, status, ASN1_INTEGER),
* ctx->certConf_cb_arg, which has been initialized using opt_out_trusted, and
* ctx->untrusted, which at this point already contains msg->extraCerts.
* Returns 0 on acceptance, else a bit field reflecting PKIFailureInfo.
- * Quoting from RFC 4210 section 5.1. Overall PKI Message:
+ * Quoting from RFC 9810 section 5.1. Overall PKI Message:
* The extraCerts field can contain certificates that may be useful to
* the recipient. For example, this can be used by a CA or RA to
* present an end entity with certificates that it needs to verify its
- * own new certificate (if, for example, the CA that issued the end
+ * own new certificate (for example, if the CA that issued the end
* entity's certificate is not a root CA for the end entity). Note that
* this field does not necessarily contain a certification path; the
* recipient may have to sort, select from, or otherwise process the
crt = X509_dup(coec->value.certificate);
break;
case OSSL_CMP_CERTORENCCERT_ENCRYPTEDCERT:
- /* cert encrypted for indirect PoP; RFC 4210, 5.2.8.2 */
+ /* cert encrypted for indirect PoP; RFC 9810, 5.2.8.3.2 */
pkey = OSSL_CMP_CTX_get0_newPkey(ctx, 1);
/* pkey is ctx->newPkey (if private, else NULL) or ctx->pkey */
if (pkey == NULL) {
goto err;
/*
- * As required by RFC 4210 section 5.1.1., if the sender name is not known
+ * As required by RFC 9810 section 5.1.1., if the sender name is not known
* to the client it set to NULL-DN. In this case for identification at least
* the senderKID must be set, where we took the referenceValue as fallback.
*/
}
if (verify_PBMAC(ctx, msg)) {
/*
- * RFC 4210, 5.3.2: 'Note that if the PKI Message Protection is
+ * RFC 9810, 5.3.2: 'Note that if the PKI message protection is
* "shared secret information", then any certificate transported in
* the caPubs field may be directly trusted as a root CA
* certificate by the initiator.'
return 0;
/*
- * RFC 4210 section 5.1.1 states: the recipNonce is copied from
+ * RFC 9810 section 5.1.1 states: the recipNonce is copied from
* the senderNonce of the previous message in the transaction.
* --> Store for setting in next message
*/
if (ossl_cmp_hdr_get_protection_nid(hdr) == NID_id_PasswordBasedMAC) {
/*
- * RFC 4210, 5.3.2: 'Note that if the PKI Message Protection is
+ * RFC 9810, 5.3.2: 'Note that if the PKI message protection is
* "shared secret information", then any certificate transported in
* the caPubs field may be directly trusted as a root CA
* certificate by the initiator.'
/*
* Decrypts the certificate in the given encryptedValue using private key pkey.
- * This is needed for the indirect PoP method as in RFC 4210 section 5.2.8.2.
+ * This is needed for the indirect PoP method as in RFC 9810 section 5.2.8.3.2.
*
* returns a pointer to the decrypted certificate
* returns NULL on error or if no certificate available
}
/*-
* Decrypts the certificate in the given encryptedKey using private key pkey.
- * This is needed for the indirect PoP method as in RFC 4210 section 5.2.8.2.
+ * This is needed for the indirect PoP method as in RFC 9810 section 5.2.8.3.2.
*
* returns a pointer to the decrypted certificate
* returns NULL on error or if no certificate available
=head1 NOTES
-CMP is specified in RFC 4210 (and CRMF in RFC 4211).
+CMP is specified in RFC 9810 (and CRMF in RFC 4211).
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
If B<nm> is NULL, recipient is set to the NULL DN (the empty list of strings).
ossl_cmp_hdr_update_messagetime() (re-)sets the messageTime to the current
-system time. As written in RFC 4210, section 5.1.1:
+system time. As written in RFC 9810, section 5.1.1:
The messageTime field contains the time at which the sender created the message.
This may be useful to allow end entities to correct/check their local time for
consistency with the time on a central system.
This starts a new transaction in case ctx->transactionID is NULL.
The sender name is copied from the subject of the client cert, if any,
or else from the subject name provided for certification requests.
-As required by RFC 4210 section 5.1.1., if the sender name is not known
+As required by RFC 9810 section 5.1.1., if the sender name is not known
to the client it set to the NULL-DN. In this case for identification at least
the senderKID must be set, which we take from any referenceValue provided.
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810 (and CRMF in RFC 4211).
=head1 RETURN VALUES
records in B<ctx> the senderNonce of the received message as the new recipNonce
and learns the transaction ID if none is currently present in B<ctx>.
-Moreover, according to RFC 4210 section 5.3.2, if the message protection is
+Moreover, according to RFC 9810 section 5.3.2, if the message protection is
PBM-based then any certificates in the caPubs field are added to the list of
trusted certificates (if set via L<OSSL_CMP_CTX_set0_trusted(3)>).
This way these certs are available for validating subsequent messages in the
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
The I<ctx> parameter of ossl_cmp_msg_add_extraCerts()
and thus also of ossl_cmp_msg_protect() cannot be made I<const>
ossl_cmp_pkisi_get_status() returns the PKIStatus of I<si>, or -1 on error.
ossl_cmp_PKIStatus_to_string() returns a human-readable string representing
-the PKIStatus values as specified in RFC 4210, Appendix F.
+the PKIStatus values as specified in RFC 9810, Appendix F.
ossl_cmp_pkisi_get0_statusString() returns a direct pointer to the statusString
field contained in I<si>.
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 NAME
-openssl-cmp - Certificate Management Protocol (CMP, RFC 4210) application
+openssl-cmp - Certificate Management Protocol (CMP, RFCs 9810 and 9811) application
=head1 SYNOPSIS
=head1 DESCRIPTION
The B<cmp> command is a client implementation for the Certificate
-Management Protocol (CMP) as defined in RFC4210.
+Management Protocol (CMP) as defined in RFCs 9810 and
+its HTTP(S) transfer as defined in RFC 9811.
It can be used to request certificates from a CA server,
update their certificates,
request certificates to be revoked, and perform other types of CMP requests.
Do not send certificate confirmation message for newly enrolled certificate
without requesting implicit confirmation
to cope with broken servers not supporting implicit confirmation correctly.
-B<WARNING:> This leads to behavior violating RFC 4210.
+B<WARNING:> This leads to behavior violating RFC 9810.
=item B<-certout> I<filename>
B<WARNING:> This setting leads to unspecified behavior and it is meant
exclusively to allow interoperability with server implementations violating
-RFC 4210, e.g.:
+RFC 9810, e.g.:
=over 4
The secret is used for creating MAC-based protection of outgoing messages
and for validating incoming messages that have MAC-based protection.
The algorithm used by default is Password-Based Message Authentication Code (PBM)
-as defined in RFC 4210 section 5.1.3.1.
+as defined in RFC 9810 section 5.1.3.1.
For more information about the format of I<arg> see
L<openssl-passphrase-options(1)>.
will be included first in the extraCerts field of outgoing messages
and the signature is done with the corresponding key.
In Initialization Request (IR) messages this can be used for authenticating
-using an external entity certificate as defined in appendix E.7 of RFC 4210.
+using an external entity certificate as defined in appendix D.7 of RFC 9810.
For Key Update Request (KUR) messages this is also used as
the certificate to be updated if the B<-oldcert> option is not given.
=item B<-digest> I<name>
-Specifies name of supported digest to use in RFC 4210's MSG_SIG_ALG
+Specifies name of supported digest to use in RFC 9810's MSG_SIG_ALG
and as the one-way function (OWF) in C<MSG_MAC_ALG>.
If applicable, this is used for message protection and
proof-of-possession (POPO) signatures.
To get the names of supported MAC algorithms use C<openssl list -mac-algorithms>
and possibly combine such a name with the name of a supported digest algorithm,
e.g., hmacWithSHA256.
-Defaults to C<hmac-sha1> as per RFC 4210.
+Defaults to C<hmac-sha1>, for backward compatibility with RFC 4210.
=item B<-extracerts> I<filenames>|I<uris>
In case of negative responses, server shall send unprotected error messages,
certificate responses (IP/CP/KUP), and revocation responses (RP).
-WARNING: This setting leads to behavior violating RFC 4210.
+WARNING: This setting leads to behavior violating RFC 9810.
=item B<-accept_unprotected>
=head1 NOTES
-CMP is defined in RFC 4210. CRMF is defined in RFC 4211.
+CMP is defined in RFC 9810. CRMF is defined in RFC 4211.
=head1 RETURN VALUES
=item B<OSSL_CMP_OPT_DIGEST_ALGNID>
-The NID of the digest algorithm to be used in RFC 4210's MSG_SIG_ALG
+The NID of the digest algorithm to be used in RFC 9810's MSG_SIG_ALG
for signature-based message protection and Proof-of-Possession (POPO).
Default is SHA256.
=item B<OSSL_CMP_OPT_OWF_ALGNID>
The NID of the digest algorithm to be used as one-way function (OWF)
for MAC-based message protection with password-based MAC (PBM).
-See RFC 4210 section 5.1.3.1 for details.
+See RFC 9810 section 5.1.3.1 for details.
Default is SHA256.
=item B<OSSL_CMP_OPT_MAC_ALGNID>
The NID of the MAC algorithm to be used for message protection with PBM.
-Default is HMAC-SHA1 as per RFC 4210.
+Default is HMAC-SHA1, for backward compatibility with RFC 4210.
=item B<OSSL_CMP_OPT_REVOCATION_REASON>
not supporting implicit confirmation correctly.
B<WARNING:> This setting leads to unspecified behavior and it is meant
exclusively to allow interoperability with server implementations violating
-RFC 4210.
+RFC 9810.
=item B<OSSL_CMP_OPT_UNPROTECTED_SEND>
revocation responses (RP) with rejection.
B<WARNING:> This setting leads to unspecified behavior and it is meant
exclusively to allow interoperability with server implementations violating
-RFC 4210.
+RFC 9810.
=item B<OSSL_CMP_OPT_IGNORE_KEYUSAGE>
OSSL_CMP_CTX_set1_referenceValue() sets the given referenceValue I<ref> with
length I<len> in the given I<ctx> or clears it if the I<ref> argument is NULL.
-According to RFC 4210 section 5.1.1, if no value for the sender field in
+According to RFC 9810 section 5.1.1, if no value for the sender field in
CMP message headers can be determined (i.e., no CMP signer certificate
and no subject DN is set via OSSL_CMP_CTX_set1_subjectName()
then the sender field will contain the NULL-DN
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810 (and CRMF in RFC 4211).
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210.
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210.
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 DESCRIPTION
-ITAV is short for InfoTypeAndValue. This type is defined in RFC 4210
+ITAV is short for InfoTypeAndValue. This type is defined in RFC 9810
section 5.3.19 and Appendix F. It is used at various places in CMP messages,
e.g., in the generalInfo PKIHeader field, to hold a key-value pair.
=head1 NOTES
-CMP is defined in RFC 4210 and RFC 9480 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
OIDs to use as types in B<OSSL_CMP_ITAV> can be found at
L<https://datatracker.ietf.org/doc/html/rfc9480#section-4.2.2>.
=head1 NOTES
-CMP is defined in RFC 4210.
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210.
-HTTP transfer for CMP is defined in RFC 6712.
+CMP is defined in RFC 9810.
+HTTP transfer for CMP is defined in RFC 9811.
=head1 RETURN VALUES
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810 (and CRMF in RFC 4211).
So far the CMP server implementation is limited to one request per CMP message
(and consequently to at most one response component per CMP message).
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
of the certificate set by L<OSSL_CMP_CTX_set1_oldCert(3)>,
otherwise the subject DN and public key
of the certificate signing request set by L<OSSL_CMP_CTX_set1_p10CSR(3)>.
-RFC 4210 is vague in which PKIStatus should be returned by the server.
+RFC 9810 is vague in which PKIStatus should be returned by the server.
We take "accepted" and "grantedWithMods" as clear success and handle
"revocationWarning" and "revocationNotification" just as warnings because CAs
typically return them as an indication that the certificate was already revoked.
This can be used, for instance,
with infoType C<signKeyPairTypes> to obtain the set of signature
algorithm identifiers that the CA will certify for subject public keys.
-See RFC 4210 section 5.3.19 and appendix E.5 for details.
+See RFC 9810 section 5.3.19 and appendix D.5 for details.
Functions implementing more specific genm/genp exchanges are described next.
OSSL_CMP_get1_caCerts() uses a genm/genp message exchange with infoType caCerts
with infoType rootCaCert to obtain from the CMP server referenced by I<ctx>
in a genp response message with infoType rootCaKeyUpdate any update of the
given root CA certificate I<oldWithOld> and verifies it as far as possible.
-See RFC 4210 section 4.4 for details.
+See RFC 9810 section 4.4 for details.
On success it assigns to I<*newWithNew> the root certificate received.
When the I<newWithOld> and I<oldWithNew> output parameters are not NULL,
it assigns to them the corresponding transition certificates.
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810 (and CRMF in RFC 4211).
The CMP client implementation is limited to one request per CMP message
(and consequently to at most one response component per CMP message).
=head1 NOTES
-CMP is defined in RFC 4210 (and CRMF in RFC 4211).
+CMP is defined in RFC 9810.
=head1 RETURN VALUES
OSSL_CRMF_ENCRYPTEDKEY_get1_encCert() decrypts the certificate in the given
encryptedKey I<ecert>, using the private key I<pkey>, library context
I<libctx> and property query string I<propq> (see L<OSSL_LIB_CTX(3)>).
-This is needed for the indirect POPO method as in RFC 4210 section 5.2.8.2.
+This is needed for the indirect POPO method as in RFC 9810 section 5.2.8.3.2.
The function returns the decrypted certificate as a copy, leaving its ownership
with the caller, who is responsible for freeing it.
OSSL_CRMF_ENCRYPTEDVALUE_get1_encCert() decrypts the certificate in the given
encryptedValue I<ecert>, using the private key I<pkey>, library context
I<libctx> and property query string I<propq> (see L<OSSL_LIB_CTX(3)>).
-This is needed for the indirect POPO method as in RFC 4210 section 5.2.8.2.
+This is needed for the indirect POPO method as in RFC 9810 section 5.2.8.3.2.
The function returns the decrypted certificate as a copy, leaving its ownership
with the caller, who is responsible for freeing it.
The algorithms for the OWF (one-way function) and for the MAC (message
authentication code) may be any with a NID defined in F<< <openssl/objects.h> >>.
-As specified by RFC 4210, these should include NID_hmac_sha1.
+For backward compatibility with RFC 4210, these should include NID_hmac_sha1.
-RFC 4210 recommends that the salt SHOULD be at least 8 bytes (64 bits) long,
+RFC 4210 recommended that the salt SHOULD be at least 8 bytes (64 bits) long,
where 16 bytes is common.
The iteration count must be at least 100, as stipulated by RFC 4211, and is
limited to at most 100000 to avoid DoS through manipulated or otherwise
malformed input.
+See RFC 9045 for currently suggested values.
=head1 RETURN VALUES
=head3 Other major new features
-=head4 Certificate Management Protocol (CMP, RFC 4210)
+=head4 Certificate Management Protocol (CMP, RFC 9810)
-This also covers CRMF (RFC 4211) and HTTP transfer (RFC 6712)
+This also covers CRMF (RFC 4211) and HTTP transfer (RFC 9811)
See L<openssl-cmp(1)> and L<OSSL_CMP_exec_certreq(3)> as starting points.
=head4 HTTP(S) client
projects / thirdparty / openssl.git / commitdiff
