Simple Certificate Enrolment ProtocolUniversity of AucklandDepartment of Computer ScienceAucklandNew Zealandpgut001@cs.auckland.ac.nzSecurity Area
Internet-Draft
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a
PKI protocol that leverages existing technology by using CMS (formerly known
as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment
protocol sponsored by Cisco Systems, which enjoys wide support in both client
and server implementations, as well as being relied upon by numerous other
industry standards that work with certificates.
X.509 certificates serve as the basis for several standards-based security
protocols such as TLS,
S/MIME, and IKE/IPsec. When an X.509
certificate is issued there typically is a need for a certificate management
protocol to enable a PKI client to request or renew a certificate from a
Certificate Authority (CA).
This specification defines a protocol, Simple Certificate Enrolment Protocol
(SCEP), for certificate management and certificate and CRL queries. While
widely deployed (see the Background Notes
section for more on the history behind SCEP and the nearly two decade-long
progress of this standard), this protocol omits some certificate management
features, e.g. certificate revocation transactions, which may enhance the
security achieved in a PKI. The IETF protocol suite currently includes two
further certificate management protocols with more comprehensive
functionality, Certificate Management Protocol (CMP)
and Certificate Management over CMS (CMC).
Environments that do not require interoperability with SCEP implementations
MAY consider using the above-mentioned certificate management protocols,
however anyone considering this step should be aware that the high level of
complexity of these two protocols has resulted in serious interoperability
problems and corresponding lack of industry support. SCEP's simplicity, while
being a drawback in terms of its slightly restricted functionality, also makes
deployment relatively straightforward, so that it enjoys widespread support
and ready interoperability across a range of platforms. While implementers
are encouraged to investigate one of the more comprehensive alternative
certificate management protocols in addition to the protocol defined in this
specification, anyone wishing to deploy them should proceed with caution, and
consider support and interoperability issues before committing to their use.
The SCEP protocol supports the following general operations:
CA public key distribution.Certificate enrolment and issue.Certificate renewal.Certificate query.CRL query.
SCEP makes extensive use of CMS and PKCS #10.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
This section provides a high level overview of the functionality of SCEP.
The entity types defined in SCEP are a client requesting a certificate and a
Certificate Authority (CA) that issues the certificate. These are described
in the following sections.
A client MUST have the following information locally configured:
The CA fully qualified domain name or IP address.The CA HTTP CGI script path (this usually has a default value,
see ).The identifying information that is used for authentication of
the CA in , typically a certificate
fingerprint.
A SCEP CA is the entity that signs client certificates. A CA MAY enforce any
arbitrary policies and apply them to certificate requests, and MAY reject a
request for any reason.
Since the client is expected to perform signature verification and optionally
encryption using the CA certificate, the keyUsage extension in the CA
certificate MUST indicate that it is valid for digitalSignature and
keyEncipherment (if available) alongside the usual CA usages of keyCertSign
and/or cRLSign.
If the CA certificate(s) have not previously been acquired by the client
through some other means, the client MUST retrieve them before any PKI
operation () can be started. Since no public key
has yet been exchanged between the client and the CA, the messages cannot be
secured using CMS, and the data is instead transferred in the clear.
If an intermediate CA is in use, a certificates-only CMS Signed-Data message
with a certificate chain consisting of all CA certificates is returned.
Otherwise the CA certificate itself is returned.
The CA certificate MAY be provided out-of-band to the client. Alternatively,
the CA certificate fingerprint MAY be used to authenticate a CA Certificate
distributed by the GetCACert response () or via
HTTP certificate-store access. The
fingerprint is created by calculating a SHA-256 hash over the whole CA
certificate (for legacy reasons, a SHA-1 hash may be used by some
implementations).
After the client gets the CA certificate, it SHOULD authenticate the
certificate by comparing its fingerprint with the locally configured,
out-of-band distributed, identifying information, or by some equivalent means
such as a direct comparison with a locally-stored copy of the certificate.
Intermediate CA certificates, if any, are signed by a higher-level CA so there
is no need to authenticate them against the out-of-band data. Clients SHOULD
verify intermediate-level CA certificate signatures using the issuing CA's
certificate before use during protocol exchanges.
When a CA certificate expires, certificates that have been signed by it may no
longer be regarded as valid. CA key rollover provides a mechanism by which
the CA MAY distribute a new CA certificate which is valid in the future once
the current certificate has expired. This is done in the GetNextCACert
message (section ).
As with every protocol that uses public-key cryptography, the association
between the public keys used in the protocol and the identities with which
they are associated must be authenticated in a cryptographically secure
manner. The communications between the client and the CA are secured using
SCEP Secure Message Objects as explained in ,
which specifies how CMS is used to encrypt and sign the data. In order to
perform the signing operation the client uses an appropriate local
certificate:
If the client does not have an appropriate existing certificate
then a locally generated self-signed certificate MUST be used. The
keyUsage extension in the certificate MUST indicate that it is valid
for digitalSignature and keyEncipherment (if available). The
self-signed certificate SHOULD use the same subject name as in the
PKCS #10 request. In this case the messageType is PKCSReq (see
).If the requesting system already has a certificate issued by the
SCEP CA and the CA supports renewal (see ), that certificate SHOULD be used.
In this case the messageType is RenewalReq (see ).Alternatively, if the requesting system has no certificate issued
by the SCEP CA but has credentials from an alternate CA then the
certificate issued by the alternate CA MAY be used in a renewal
request as described above. Policy settings on the SCEP CA will
determine if the request can be accepted or not.
Note that although the above text describes several different types of
operations, in practice most implementations always apply the first one even
if an existing certificate already exists. For this reason support for the
first case is mandatory while support for the latter ones are optional (see
).
During the certificate enrolment process, the client MUST use the selected
certificate's key when signing the CMS envelope (see ). This certificate will be either the self-signed one
matching the PKCS #10 request or the CA-issued one used to authorise a
renewal, and MUST be included in the signedData certificates field (possibly
as part of a full certificate chain). If the key being certified allows
encryption then the CA's CertResp will use the same certificate's public key
when encrypting the response.
Note that this means that, in the case of renewal operations, the request is
signed with, and the returned response may be encrypted with, the key in the
previously-issued certificate used to authenticate the request, not the key in
the PKCS #10 request. This has security implications, see .
PKCS #10 specifies a PKCS
#9 challengePassword attribute to be sent as part of the enrolment
request. When utilizing the challengePassword, the CA distributes a shared
secret to the client which will uniquely associate the enrolment request with
the client.
Inclusion of the challengePassword by the SCEP client is OPTIONAL and allows
for unauthenticated authorization of enrolment requests (which, however,
requires manual approval of each certificate issue, see below), or for renewal
requests that are authenticated by being signed with an existing certificate.
The CMS envelope protects the privacy of the challengePassword.
A client that is performing certificate renewal as per SHOULD omit the challengePassword but MAY send
the originally distributed password in the challengePassword attribute. The
SCEP CA MAY use the challengePassword in addition to the previously issued
certificate that signs the request to authenticate the request. The SCEP CA
MUST NOT attempt to authenticate a client based on a self-signed certificate
unless it has been verified through out-of-band means such as a certificate
fingerprint.
To perform the authorization in manual mode the client's request is placed in
the PENDING state until the CA operator authorizes or rejects it. Manual
authorization is used when the client has only a self-signed certificate that
hasn't been previously authenticated by the CA and/or a challengePassword is
not available. The SCEP CA MAY either reject unauthorized requests or mark
them for manual authorization according to CA policy.
A client starts an enrolment transaction () by
creating a certificate request using PKCS #10 and sends it to the CA enveloped
using CMS ().
If the CA supports certificate renewal and if the CA policy permits then a new
certificate with new validity dates can be issued even though the old one is
still valid. The CA MAY automatically revoke the old client certificate. To
renew an existing certificate, the client uses the RenewalReq message (see
) and signs it with the existing client
certificate. The client SHOULD use a new keypair when requesting a new
certificate, but MAY request a new certificate using the old keypair.
If the CA returns a CertRep message () with status set
to PENDING, the client enters into polling mode by periodically sending a
CertPoll message () to the CA until the CA operator
completes the manual authentication (approving or denying the request).
If polling mode is being used then the client will send a single
PKCSReq/RenewalReq message (), followed by 0 or more
CertPoll messages (). The CA will in return send 0
or more CertRep messages () with status set to PENDING
in response to CertPolls, followed by a single CertRep message () with status set to either SUCCESS or FAILURE.
The client state transitions during the SCEP process are indicated in .
[CERT-REQ-PENDING] ---------> [CERT-ISSUED]
^ PKCSReq | CertRep(SUCCESS)
| RenewalReq |
| |
+-----------------------+
CertRep(FAILURE) or
Max-time/max-polls exceeded
]]>
The certificate issue process starts at state CERT-NONEXISTENT. Sending a
PKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING.
If the CA returns a CertRep message with pkiStatus set to SUCCESS then the
state changes to CERT-ISSUED.
If the CA returns a CertRep message with pkiStatus set to FAILURE or there is
no response then the state reverts back to CERT-NONEXISTENT.
If the CA returns a CertRep message with pkiStatus set to PENDING then the
client will keep polling by sending a CertPoll message until either a CertRep
message with status set to SUCCESS or FAILURE is received or a timeout occurs
or the maximum number of polls has been exceeded.
A successful transaction in automatic mode: CertRep: pkiStatus = SUCCESS
Certificate attached
A successful transaction in manual mode: CertRep: pkiStatus = PENDING
CertRep: pkiStatus = PENDING
...............
CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached
A certificate query message is defined for clients to retrieve a copy of their
own certificate from the CA. It allows clients that do not store their
certificates locally to obtain a copy when needed. This functionality is not
intended to provide a general purpose certificate access service, which may be
achieved via HTTP certificate-store
access or LDAP.
To query a certificate from the CA, a client sends a request consisting of the
certificate's issuer name and serial number. This assumes that the client has
saved the issuer name and the serial number of the issued certificate from the
previous enrolment transaction. The transaction to query a certificate
consists of one GetCert () message and one CertRep
() message, as shown below.
CertRep: pkiStatus = SUCCESS
Certificate attached
SCEP clients MAY request a CRL via one of three methods:
If the CA supports CRL Distribution Points
(CRLDPs), then the CRL MAY be retrieved via the mechanism
specified in the CRDLP.If the CA supports HTTP
certificate-store access, then the CRL MAY be retrieved via
the AuthorityInfoAcces location specified
in the certificate.Only if the CA does not support CRDLPs or HTTP access should a
CRL query be composed by creating a GetCRL message consisting of the
issuer name and serial number from the certificate whose revocation
status is being queried.
The CA SHOULD NOT support the GetCRL method because it does not scale well due
to the unnecessary cryptography (see )
and it requires the CA to be a high-availability service.
The message is sent to the SCEP CA in the same way as the other SCEP requests.
The transaction to retrieve a CRL consists of one GetCRL PKI message and one
CertRep PKI message, which contains only the CRL (no certificates) in a
degenerate certificates-only CMS Signed-Data message
(), as shown below.
CertRep: CRL attached
SCEP does not specify a method to request certificate revocation. In order to
revoke a certificate, the client must contact the CA using a non-SCEP defined
mechanism.
At a minimum, all SCEP implementations compliant with this specification MUST
support GetCACaps, GetCACert, PKCSReq
(and its associated response messages), communication of binary data via HTTP POST, and the AES and SHA-256 algorithms to
secure pkiMessages.
For historical reasons implementations MAY support communications of binary
data via HTTP GET, and the triple DES and
SHA-1 algorithms to secure pkiMessages.
Implementations MUST NOT support the obsolete and/or insecure single DES and
MD5 algorithms used in earlier versions of this specification, since the
unsecured nature of GetCACaps means that an in-path attacker can trivially
roll back the encryption used to these insecure algorithms, see .
CMS is a general enveloping mechanism that enables both signed and encrypted
transmission of arbitrary data. SCEP messages that require confidentiality
use two layers of CMS, as shown in . By applying
both enveloping and signing transformations, the SCEP message is protected
both for the integrity of its end-to-end transaction information and the
confidentiality of its information portion. Some messages do not require
enveloping, in which case the EnvelopedData in
is omitted.
When a particular SCEP message carries data, this data is carried in the
messageData. CertRep messages will lack any signed content and consist only
of a pkcsPKIEnvelope ().
The remainder of this document will refer only to 'messageData', but it is
understood to always be encapsulated in the pkcsPKIEnvelope (). The format of the data in the messageData is
defined by the messageType attribute (see ) of the
Signed-Data. If there is no messageData to be transmitted, the entire
pkcsPKIEnvelope MUST be omitted.
Samples of SCEP messages are available through the
JSCEP project in the src/samples directory.
Creating a SCEP message consists of several stages. The content to be
conveyed (in other words the messageData) is first encrypted, and the
encrypted content is then signed.
The form of encryption to be applied depends on the capabilities of the
recipient's public key. If the key is encryption-capable (for example RSA)
then the messageData is encrypted using the recipient's public key with the
CMS KeyTransRecipientInfo mechanism. If the key is not encryption-capable
(for example DSA or ECDSA) then the messageData is encrypted using the
challengePassword with the CMS PasswordRecipientInfo mechanism.
Once the messageData has been encrypted, it is signed with the sender's public
key. This completes the SCEP message that is then sent to the recipient.
Note that some earlier implementations of this specification dealt with
non-encryption-capable keys by omitting the encryption stage, based on the
text in that indicated that "the EnvelopedData is
omitted". This alternative processing mechanism SHOULD NOT be used since it
exposes the challengePassword used to authorise the certificate issue.
The basic building block of all secured SCEP messages is the SCEP pkiMessage.
It consists of a CMS Signed-Data content type. The following restrictions
apply:
The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7
1}).The signed content, if present (FAILURE and PENDING CertRep
messages will lack any signed content), MUST be a pkcsPKIEnvelope
(), and MUST match the
messageType attribute.The SignerInfo MUST contain a set of authenticatedAttributes
().
At a minimum, all messages MUST contain the following authenticatedAttributes:
A transactionID attribute (see ).A messageType attribute (see ).A fresh senderNonce attribute (see ).Any attributes required by CMS.
If the message is a CertRep, it MUST also include the following
authenticatedAttributes:
A pkiStatus attribute (see ).A failInfo and optional failInfotext attribute (see ) if pkiStatus = FAILURE.A recipientNonce attribute (see ) copied
from the senderNonce in the request that this is a response
to.
The following transaction attributes are encoded as authenticated attributes,
and are carried in the SignerInfo for this Signed-Data.
AttributeEncodingCommenttransactionIDPrintableStringUnique ID for this
transaction as a text stringmessageTypePrintableStringDecimal value as a
numeric text stringpkiStatusPrintableStringDecimal value as a
numeric text stringfailInfoPrintableStringDecimal value as a
numeric text stringfailInfoTextUTF8StringDescriptive text for the
failInfo valuesenderNonceOCTET STRINGRandom nonce as a 16-byte
binary data stringrecipientNonceOCTET STRINGRandom nonce as a
16-byte binary data stringThe OIDs used for these attributes are as
follows:NameASN.1 Definitionid-VeriSignOBJECT_IDENTIFIER ::= {2 16 US(840) 1
VeriSign(113733)}id-pkiOBJECT_IDENTIFIER ::= {id-VeriSign pki(1)}id-attributesOBJECT_IDENTIFIER ::= {id-pki
attributes(9)}id-transactionIDOBJECT_IDENTIFIER ::= {id-attributes
transactionID(7)}id-messageTypeOBJECT_IDENTIFIER ::= {id-attributes
messageType(2)}id-pkiStatusOBJECT_IDENTIFIER ::= {id-attributes
pkiStatus(3)}id-failInfoOBJECT_IDENTIFIER ::= {id-attributes
failInfo(4)}id-senderNonceOBJECT_IDENTIFIER ::= {id-attributes
senderNonce(5)}id-recipientNonceOBJECT_IDENTIFIER ::= {id-attributes
recipientNonce(6)}id-scepOBJECT IDENTIFIER ::= {id-pkix TBD1}id-scep-failInfoTextOBJECT IDENTIFIER ::= {id-scep 1}
The attributes are detailed in the following sections.
A PKI operation is a transaction consisting of the messages exchanged between
a client and the CA. The transactionID is a text string provided by the
client when starting a transaction. The client MUST use a unique string as
the transaction identifier, encoded as a PrintableString, which MUST be used
for all PKI messages exchanged for a given operation such as a certificate
issue.
Note that the transactionID must be unique, but not necessarily randomly
generated. For example it may be a value assigned by the CA (alongside the
challengePassword) as an equivalent to the traditional user name + password,
so that the client is identified by their transactionID. This can be useful
when the client doesn't have a pre-assigned Distinguished Name that the CA can
identify their request through, for example when enrolling SCADA devices.
The messageType attribute specifies the type of operation performed by the
transaction. This attribute MUST be included in all PKI messages. The
following message types are defined:
CertRep ("3") -- Response to certificate or CRL request.RenewalReq ("17") -- PKCS #10 certificate request
authenticated with an existing certificate.PKCSReq ("19") -- PKCS #10 certificate request authenticated
with a password.CertPoll ("20") -- Certificate polling in manual enrolment.GetCert ("21") -- Retrieve a certificate.GetCRL ("22") -- Retrieve a CRL.
Undefined message types MUST BE treated as an error.
All response messages MUST include transaction status information, which is
defined as a pkiStatus attribute:
SUCCESS ("0") -- Request granted.FAILURE ("2") -- Request rejected. In this case the failInfo
attribute, as defined in , MUST also
be present.PENDING ("3") -- Request pending for manual approval.
Undefined pkiStatus attributes MUST be treated as an error.
The failInfo attribute MUST contain one of the following failure reasons:
badAlg ("0") -- Unrecognized or unsupported algorithm.badMessageCheck ("1") -- Integrity check (meaning signature
verification of the CMS message) failed.badRequest ("2") -- Transaction not permitted or
supported.badTime ("3") -- The signingTime attribute from the CMS
authenticatedAttributes was not sufficiently close to the
system time (this failure code is present for legacy reasons
and is unlikely to be encountered in practice).badCertId ("4") -- No certificate could be identified
matching the provided criteria.
The failInfoText is a free-form UTF-8 text string that provides further
information in the case of pkiStatus = FAILURE. In particular it may be used
to provide details on why a certificate request was not granted that go beyond
what's provided by the near-universal failInfo = badRequest status. Since
this is a free-form text string intended for interpretation by humans,
implementations SHOULD NOT assume that it has any type of machine-processable
content.
The senderNonce and recipientNonce attributes are a 16 byte random number
generated for each transaction. These are intended to prevent replay attacks.
When a sender sends a PKI message to a recipient, a fresh senderNonce MUST be
included in the message. The recipient MUST copy the senderNonce into the
recipientNonce of the reply as a proof of liveliness. The original sender
MUST verify that the recipientNonce of the reply matches the senderNonce it
sent in the request. If the nonce does not match, the message MUST be
rejected.
Note that since SCEP exchanges consist of a single request followed by a
single response, the use of distinct sender and recipient nonces is redundant
since the client sends a nonce in its request and the CA responds with the
same nonce in its reply. In effect there's just a single nonce, identified as
senderNonce in the client's request and recipientNonce in the CA's reply.
The information portion of a SCEP message is carried inside an EnvelopedData
content type, as defined in CMS, with the following restrictions:
contentType in encryptedContentInfo MUST be data ({pkcs-7
1}).encryptedContent MUST be the SCEP message being transported
(see ), and must match the
messageType authenticated Attribute in the pkiMessage.
All of the messages in this section are pkiMessages (), where the type of the message MUST be specified in the
'messageType' authenticated Attribute. Each section defines a valid message
type, the corresponding messageData formats, and mandatory authenticated
attributes for that type.
The messageData for this type consists of a PKCS #10 Certificate Request. The
certificate request MUST contain at least the following items:
The subject Distinguished Name.The subject public key.For a PKCSReq and if authorisation based on a password is being
used, a challengePassword attribute.
In addition to the authenticatedAttributes required for a valid CMS message,
the pkiMessage MUST include the following attributes:
A transactionID attribute ().A messageType attribute () set to
PKCSReq or RenewalReq as appropriate.A fresh senderNonce attribute ().
The messageData for this type consists of a degenerate certificates-only CMS
Signed-Data message (). The exact content required
for the reply depends on the type of request that this message is a response
to. The request types are detailed in and in
.
In addition to the authenticatedAttributes required for a valid CMS message,
this pkiMessage MUST include the following attributes:
The transactionID attribute ()
copied from the request that this is a response to.A messageType attribute () set to
CertRep.A recipientNonce attribute () copied
from the senderNonce in the request that this is a response
to.A pkiStatus attribute () set to the
status of the reply.
Earlier versions of this specification required that this message include a
senderNonce alongside the recipientNonce, which was to be used to chain to
subsequent polling operations. However if a single message was lost during
the potentially extended interval over which polling could take place (see
for an example of this) then if the
implementation were to enforce this requirement the overall transaction would
fail even though nothing had actually gone wrong. Because of this issue,
implementations mostly ignored the requirement to carry this nonce over to
subsequent polling messages or to verify its presence. Current versions of
the specification no longer require the chaining of nonces across polling
operations.
When the pkiStatus attribute is set to SUCCESS, the messageData for this
message consists of a degenerate certificates-only CMS Signed-Data message
(). The content of this degenerate
certificates-only Signed-Data depends on what the original request was, as
outlined below.
Request-typeReply-contentsPKCSReqThe reply MUST contain at least the issued
certificate in the certificates field of the Signed-Data.
The reply MAY contain additional certificates, but the issued
certificate MUST be the leaf certificate.RenewalReqSame as PKCSReqCertPollSame as PKCSReqGetCertThe reply MUST contain at least the requested
certificate in the certificates field of the Signed-Data.
The reply MAY contain additional certificates, but the
requested certificate MUST be the leaf certificate.GetCRLThe reply MUST contain the CRL in the crls field
of the Signed-Data.
When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a
failInfo () attribute set to the appropriate error
condition describing the failure. The reply MAY also contain a failInfoText
attribute providing extended details on why the operation failed, typically to
expand on the catch-all failInfo = badRequest status. The pkcsPKIEnvelope
() MUST be omitted.
When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope () MUST be omitted.
This message is used for certificate polling. For unknown reasons it was
referred to as "GetCertInitial" in earlier versions of this specification.
The messageData for this type consists of an IssuerAndSubject:
The issuer is set to the subjectName of the CA (in other words the intended
issuerName of the certificate that's being requested). The subject is set to
the subjectName used when requesting the certificate.
Note that both of these fields are redundant, the CA is identified by the
recipientInfo in the pkcsPKIEnvelope (or in most cases simply by the server
that the message is being sent to) and the client/transaction being polled is
identified by the transactionID. Both of these fields can be processed by the
CA without going through the cryptographically expensive process od unwrapping
and processing the issuerAndSubject. For this reason implementations SHOULD
assume that the polling operation will be controlled by the recipientInfo and
transactionID rather than the contents of the messageData.
In addition to the authenticatedAttributes required for a valid CMS message,
this pkiMessage MUST include the following attributes:
The same transactionID ()
attribute from the original PKCSReq/RenewalReq message.A messageType attribute () set to
CertPoll.A fresh senderNonce attribute ().
The messageData for these types consist of an IssuerAndSerialNumber as defined
in CMS which uniquely identifies the certificate being requested, either the
certificate itself for GetCert or its revocation status via a CRL for GetCRL.
In addition to the authenticatedAttributes required for a valid CMS message,
this pkiMessage MUST include the following attributes:
A transactionID attribute ().A messageType attribute () set to
GetCert or GetCRL.A fresh senderNonce attribute ().
A self-signed certificate MAY be used in the signed envelope. This enables
the client to request their own certificate if they were unable to store it
previously.
These message types, while included here for completeness, apply unnecessary
cryptography and messaging overhead to the simple task of transferring a
certificate or CRL (see ).
Implementations SHOULD prefer
HTTP certificate-store access or LDAP
over the use of these messages.
CMS includes a degenerate case of the Signed-Data content type in which there
are no signers. The use of such a degenerate case is to disseminate
certificates and CRLs. For SCEP the content field of the ContentInfo value of
a degenerate certificates-only Signed-Data MUST be omitted.
When carrying certificates, the certificates are included in the
'certificates' field of the Signed-Data. When carrying a CRL, the CRL is
included in the 'crls' field of the Signed-Data.
In order to provide support for future enhancements to the protocol, CAs MUST
implement the GetCACaps message to allow clients to query which functionality
is available from the CA.
This message requests capabilities from a CA, with the
format:
with the message components as described in .
The response for a GetCACaps message is a list of CA
capabilities, in plain text, separated by
<CR><LF> or <LF> characters, as
follows (quotation marks are NOT sent):KeywordDescription"AES"CA supports the AES encryption algorithm."DES3"CA supports the triple DES encryption
algorithm."GetNextCACert"CA supports the GetNextCACert
message."POSTPKIOperation"CA supports PKIOPeration messages sent
via HTTP POST."Renewal"CA supports the Renewal CA operation."SHA-1"CA supports the SHA-1 hashing algorithm."SHA-256"CA supports the SHA-256 hashing algorithm."SHA-512"CA supports the SHA-512 hashing algorithm."SCEPStandard"CA supports all mandatory-to-implement
sections of the SCEP standard. This keyword implies "AES",
"POSTPKIOperation", and "SHA-256", as well as the provisions of
.
The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES in
preference to triple DES if they are supported by the CA. Although the CMS
format allows any form of AES and SHA-2 to be specified, in the interests of
interoperability the de facto universal standards of AES128-CBC and SHA-256
SHOULD be used.
Announcing some of these capabilities individually is redundant since they're
required as mandatory-to-implement functionality (see )
whose presence as a whole is signalled by the "SCEPStandard" capability, but
it may be useful to announce them in order to deal with old implementations
that would otherwise default to obsolete, insecure algorithms and mechanisms.
The CA MUST use the text case specified here, but clients SHOULD ignore the
text case when processing this message. Clients MUST accept the standard
HTTP-style <CR><LF>-delimited text as well as the <LF>-
delimited text specified in an earlier version of this specification. A
client MUST be able to accept and ignore any unknown keywords that might be
sent back by a CA.
If the CA supports none of the above capabilities it SHOULD return an empty
message. A CA MAY simply return an HTTP error. A client that receives an
empty message or an HTTP error SHOULD interpret the response as if none of the
requested capabilities are supported by the CA.
(Note that at least one widely-deployed server implementation supports several
of the above operations but doesn't support the GetCACaps message to indicate
that it supports them, and will close the connection if sent a GetCACaps
message. This means that the equivalent of GetCACaps must be performed
through server fingerprinting, which can be done using the ID string
"Microsoft-IIS". Newer versions of the same server, if sent a SCEP request
using AES and SHA-2, will respond with an invalid response that can't be
decrypted, requiring the use of 3DES and SHA-1 in order to obtain a response
that can be processed even if AES and/or SHA-2 are allegedly supported. In
addition the server will generate CA certificates that only have one, but not
both, of the keyEncipherment and digitalSignature keyUsage flags set,
requiring that the client ignore the keyUsage flags in order to use the
certificates for SCEP).
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore
the Content-type, as older implementations of SCEP may send various
Content-types.
Example:might return:
This means that the CA supports modern crypto algorithms, the GetNextCACert
message, allows PKIOperation messages (PKCSReq/RenewalReq, GetCert, CertPoll,
...) to be sent using HTTP POST, and is compliant with the final version of
the SCEP standard.
This section describes the SCEP Transactions and their
HTTP transport mechanism.
SCEP uses the HTTP "POST" and "GET" messages to exchange information with the
CA. The following defines the syntax of HTTP POST and GET messages sent from
a client to a CA:
where:
CGI-PATH defines the path to invoke the CGI program that parses
the request.CGI-PROG is set to be the string "pkiclient.exe". This is
intended to be the program that the CA will use to handle the SCEP
transactions.OPERATION depends on the SCEP transaction and is defined in the
following sections.
The CA will typically ignore CGI-PATH and/or CGI-PROG since it's unlikely to
be issuing certificates via a web server. Clients SHOULD set
CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" unless directed
to do otherwise by the CA. The CA SHOULD ignore the CGI-PATH and CGI-PROG
unless its precise format is critical to the CA's operation.
Early SCEP drafts performed all communications via "GET" messages, including
non-idempotent ones that should have been sent via "POST" messages. This has
caused problems because of the way that the (supposedly) idempotent GET
interacts with caches and proxies, and because the extremely large GET
requests created by encoding CMS messages may be truncated in transit. These
issues are typically not visible when testing on a LAN, but crop up during
deployment over WANs. If the remote CA supports POST, the CMS-encoded SCEP
messages MUST be sent via HTTP POST instead of HTTP GET. This applies to any
SCEP message except GetCACert, GetNextCACert, and GetCACaps, and avoids the
need for base64- and URL-encoding that's required for GET messaging. The
client can verify that the CA supports SCEP messages via POST by looking for
the "POSTPKIOperation" capability (See ).
If a client or CA uses HTTP GET and encounters HTTP-related problems such as
messages being truncated, seeing errors such as HTTP 414 ("Request URI too
long"), or simply having the message not sent/received at all, when standard
requests to the server (for example via a web browser) work, then this is a
symptom of the problematic use of HTTP GET. The solution to this problem is
to update the implementation to use HTTP POST instead. In addition when using
GET it's recommended to test your implementation over the public internet from
as many locations as possible to determine whether the use of GET will cause
problems with communications.
When using GET messages to communicate binary data, base64 encoding as
specified in MUST be used. The base64 encoded data is
distinct from "base64url" and may contain URI reserved characters, thus it
MUST be escaped as specified in in addition to being
base64 encoded. Finally, the encoded data is inserted into the MESSAGE
portion of the HTTP GET request.
To get the CA certificate(s), the client sends a GetCACert message to the CA.
The OPERATION MUST be set to "GetCACert". There is no request data associated
with this message.
The response for GetCACert is different between the case where the CA directly
communicates with the client during the enrolment and the case where an
intermediate CA exists and the client communicates with this CA during the
enrolment.
If the CA does not have any intermediate CA certificates, the response
consists of a single X.509 CA certificate. The response will have a
Content-Type of "application/x-x509-ca-cert".
]]>
If the CA has intermediate CA certificates, the response consists of a
degenerate certificates-only CMS Signed-Data message () containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s). The response will have a
Content-Type of "application/x-x509-ca-ra-cert". Note that this designation
is used for historical reasons due to its use in older versions of this
specification, no special meaning should be attached to the label.
]]>
A PKCSReq/RenewalReq () message is used to perform a
certificate enrolment or renewal transaction. The OPERATION MUST be set to
"PKIOperation". Note that when used with HTTP POST, the only OPERATION
possible is "PKIOperation", so many CAs don't check this value or even notice
its absence. When implemented using HTTP POST the message might look as
follows:
]]>
When implemented using HTTP GET this might look as follows:
If the request is granted, a CertRep message () with
pkiStatus set to SUCCESS is returned. The reply MUST also contain the
certificate (and MAY contain any other certificates needed by the client). The
issued certificate MUST be the first in the list.
If the request is rejected, a CertRep message () with
pkiStatus set to FAILURE is returned. The reply MUST also contain a failInfo
attribute and MAY contain a failInfoText attribute.
If the the CA is configured to manually authenticate the client, a CertRep
message () with pkiStatus set to PENDING MAY be
returned. The CA MAY return a PENDING for other reasons.
The response will have a Content-Type of "application/x-pki-message".
]]>
When the client receives a CertRep message with pkiStatus set to PENDING, it
will enter the polling state by periodically sending CertPoll messages to the
CA until either the request is granted and the certificate is sent back or the
request is rejected or some preconfigured time limit for polling or maximum
number of polls is exceeded. The OPERATION MUST be set to "PKIOperation".
CertPoll messages exchanged during the polling period MUST carry the same
transactionID attribute as the previous PKCSReq/RenewalReq. A CA receiving a
CertPoll for which it does not have a matching PKCSReq/RenewalReq MUST ignore
this request.
Since at this time the certificate has not been issued, the client can only
use its own subject name (which was contained in the original PKCS# 10 sent
via PKCSReq/RenewalReq) to identify the polled certificate request (but see
the note on identification during polling in ). In
theory there can be multiple outstanding requests from one client (for
example, if different keys and different key-usages were used to request
multiple certificates), so the transactionID must also be included to
disambiguate between multiple requests. In practice however the client SHOULD
NOT have multiple requests outstanding at any one time, since this tends to
confuse some CAs.
The response messages for CertPoll are the same as in .
A client can query an issued certificate from the SCEP CA, as long as the
client knows the issuer name and the issuer assigned certificate serial
number.
This transaction consists of one GetCert () message
sent to the CA by a client, and one CertRep () message
sent back from the CA. The OPERATION MUST be set to "PKIOperation".
In this case, the CertRep from the CA is same as in , except that the CA will either grant the
request (SUCCESS) or reject it (FAILURE).
Clients can request a CRL from the SCEP CA as described in . The OPERATION MUST be set to "PKIOperation".
The CRL is sent back to the client in a CertRep ()
message. The information portion of this message is a degenerate
certificates-only Signed-Data () that contains only
the most recent CRL in the crls field of the Signed-Data.
When a CA certificate is about to expire, clients need to retrieve the CA's
next CA certificate (i.e. the rollover certificate). This is done via the
GetNextCACert message. The OPERATION MUST be set to "GetNextCACert". There
is no request data associated with this message.
The response consists of a Signed-Data CMS message, signed by the current CA
signing key. Clients MUST validate the signature on the message before
accepting any of its contents. The response will have a Content-Type of
"application/x-x509-next-ca-cert".
]]>
The content of the Signed-Data message is a degenerate certificates-only
Signed-Data message () containing the new CA
certificate(s) to be used when the current CA certificate expires.
If the CA does not have rollover certificate(s) it MUST reject the request. It
SHOULD also remove the GetNextCACert setting from the CA capabilities returned
by GetCACaps until it does have rollover certificates.
The following section gives several examples of client to CA transactions.
Client actions are indicated in the left column, CA actions are indicated in
the right column, and the transactionID is given in parentheses. The first
transaction, for example, would read like this:
"Client Sends PKCSReq message with transactionID 1 to the CA. The CA signs
the certificate and constructs a CertRep Message containing the signed
certificate with a transaction ID 1. The client receives the message and
installs the certificate locally".
Successful Enrolment Case: Automatic processing CA issues certificate
Successful Enrolment Case: Manual authentication
required Cert request goes into queue
Still pending
CA issues certificate
CA certificate rollover case:
CA issues certificate with
new key
* Enveloped for the new CA certificate. The CA will use
the envelope to determine which key to use to issue the
client certificate.
In the case of polled transactions that aren't completed automatically, there
are two potential options for dealing with a transaction that's interrupted
due to network or software/hardware issues. The first is for the client to
preserve its transaction state and resume the CertPoll polling when normal
service is restored. The second is for the client to begin a new transaction
by sending a new PKCSReq/RenewalReq rather than continuing the previous
CertPoll. Both options have their own advantages and disadvantages.
The CertPoll continuation requires that the client maintain its transaction
state for the time when it resumes polling. This is relatively simple if the
problem is a brief network outage, but less simple when the problem is a
client crash and restart. In addition the CA may treat a lost network
connection as the end of a transaction, so that a new connection followed by a
CertPoll will be treated as an error.
The PKCSReq/RenewalReq continuation doesn't require any state to be maintained
since it's a new transaction, however it may cause problems on the CA side if
the certificate was successfully issued but the client never received it,
since the resumed transaction attempt will appear to be a request for a
duplicate certificate (see for more on why
this is a problem). In this case the CA may refuse the transaction, or
require manual intervention to remove/revoke the previous certificate before
the client can request another one.
Since the new-transaction resume is more robust in the presence of errors and
doesn't require special-case handling by either the client or CA, clients
SHOULD use the new-transaction option in preference to the resumed-CertPoll
option to recover from errors.
Resync Case 1: Client resyncs via new PKCSReq
(recommended): Cert request goes into queue
Still pending
X-------- CertRep(3) PENDING
(Network outage)
(Client reconnects)
PKCSReq (4) ---------->
Resync Case 2: Client resyncs via resumed CertPoll after a
network outage (not recommended, use PKCSReq to
resync): Cert request goes into queue
Still pending
X-------- CertRep(5) PENDING
(Network outage)
(Client reconnects)
CertPoll (5) ----------> CA issues certificate
Resync Case 3: Special-case variation of case 2 where the
CertRep SUCCESS rather than the CertRep PENDING is
lost (recommended): Cert request goes into queue
Still pending
CA issues certificate
X-------- CertRep(6) SUCCESS
(Network outage)
(Client reconnects)
PKCSReq (7) ----------> There is already a valid
certificate with this DN.
CA issues new certificate
Resync Case 4: Special-case variation of case 1 where the
CertRep SUCCESS rather than the CertRep PENDING is lost
(not recommended, use PKCSReq to resync): Cert request goes into queue
Still pending
CA issues certificate
X-------- CertRep(8) SIGNED CERT
(Network outage)
(Client reconnects)
CertPoll (8) ----------> Certificate already issued
As these examples indicate, resumption from an error via a resumed CertPoll is
tricky due to the state that needs to be held by both the client and/or the
CA. A PKCSReq/RenewalReq resume is the easiest to implement since it's
stateless and is identical for both polled and non-polled transactions, while
a CertPoll resume treats the two differently (a non-polled transaction is
resumed with a PKCSReq/RenewalReq, a polled transaction is resumed with a
CertPoll). For this reason error recovery SHOULD be handled via a new PKCSReq
rather than a resumed CertPoll.
The editor would like to thank all of the previous editors, authors and
contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy
Nourse, Max Pritikin, Jan Vilhuber, and others for their work maintaining the
draft over the years. Numerous other people have contributed during the long
life cycle of the draft and all deserve thanks. In addition several PKCS #7 /
CMS libraries contributed to interoperability by doing the right thing despite
what earlier SCEP drafts required.
The earlier authors would like to thank Peter William of ValiCert, Inc.
(formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. and Christopher
Welles of IRE, Inc. for their contributions to early versions of this protocol
and this document.
One object identifier for an arc to assign SCEP Attribute Identifiers was
assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry:
This assignment created the new SMI Security for SCEP Attribute Identifiers
((1.3.6.1.5.5.7.TBD1) registry with the following entries with references to
this document:
(Editor's note: When the OID is assigned, the values in the OID table in will also need to be updated).
The security goal of SCEP is that no adversary can subvert the public
key/identity binding from that intended. An adversary is any entity other
than the client and the CA participating in the protocol.
This goal is met through the use of CMS and PKCS #10 encryption and digital
signatures using authenticated public keys. The CA's public key is
authenticated via out-of-band means such as the checking of the CA fingerprint
and the SCEP client's public key is authenticated through manual or pre-shared
secret authentication.
Common key-management considerations such as keeping private keys truly
private and using adequate lengths for symmetric and asymmetric keys must be
followed in order to maintain the security of this protocol. This is
especially true for CA keys which, when compromised, compromise the security
of all relying parties.
A CA key pair is generally meant for, and is usually flagged as, being usable
for certificate (and CRL) signing exclusively rather than data signing or
encryption. The SCEP protocol however uses the CA private key to both sign
and optionally encrypt CMS transport messages. This is generally considered
undesirable as it widens the possibility of an implementation weakness and
provides an additional location where the private key must be used (and hence
is slightly more vulnerable to exposure) and where a side-channel attack might
be applied.
The challengePassword sent in the PKCS #10 enrolment request is signed and
encrypted by way of being encapsulated in a pkiMessage. When saved by the CA,
care should be taken to protect this password, for example by storing a salted
iterated hash of the password rather than the password itself.
SCEP provides no confirmation that the issued certificate was successfully
received and processed by the client. This means that if the CertRep message
is lost or can't be processed by the client then the CA will consider the
certificate successfully issued while the client won't. If this situation is
of concern then the correct issuance of the certificate will need to be
verified by out-of-band means, for example through the client sending a
message signed by the newly-issued certificate to the CA. This also provides
the proof of possession that's not present in the case of a renewal operation,
see .
The GetCACaps response is not authenticated by the CA. This allows an
attacker to perform downgrade attacks on the cryptographic capabilities of the
client/CA exchange. In particular if the server were to support MD5 and
single DES then an in-path attacker could trivially roll back the encryption
to use these insecure algorithms. By taking advantage of the presence of
large amounts of static known plaintext in the SCEP messages, as of 2017 a DES
rainbow table attack can recover most encryption keys in under a minute, and
MD5 chosen-prefix collisions can be calculated for a few tens of cents of
computing time using tools like HashClash.
Renewal operations (but not standard certificate-issue operations) are
processed via a previously-issued certificate and its associated private key,
not the key in the PKCS #10 request. This means that a client no longer
demonstrates proof of possession (PoP) of the private key corresponding to the
public key in the PKCS #10 request. It is therefore possible for a client to
re-certify an existing key used by a third party, so that two or more
certificates exist for the same key. By switching out the certificate in a
signature, an attacker can appear to have a piece of data signed by their
certificate rather than the original signer's certificate. This, and other,
attacks are described in S/MIME ESS.
Avoiding these types of attacks requires situation-specific measures. For
example CMS/SMIME implementations may use the ESSCertID attribute from S/MIME ESS or its successor S/MIME
ESSv2 to unambiguously identify the signing certificate, however other
mechanisms and protocols typically don't defend against this attack.
Some of the SCEP exchanges use unnecessary signing and encryption operations.
In particular the GetCert and GetCRL exchanges are encrypted and signed in
both directions. The information requested is public and thus encrypting the
requests is of questionable value. In addition CRLs and certificates sent in
responses are already signed by the CA and can be verified by the recipient
without requiring additional signing and encryption. More lightweight means
of retrieving certificates and CRLs such as HTTP
certificate-store access and LDAP are recommended for this reason.
Virtually all of the large numbers of devices that use SCEP today default to
SHA-1, with many supporting only that hash algorithm with no ability to
upgrade to a newer one. SHA-1 is no longer regarded as secure in all
situations, but as used in SCEP it's still safe. There are three reasons for
this. The first is that attacking SCEP would require creating a SHA-1
collision in close to real time, which won't be feasible for a very long time.
The second reason is that the signature over the message doesn't serve any
critical cryptographic purpose: The PKCS #10 data itself is authenticated
through its own signature, protected by encryption, and the overall request is
authorised by the (encrypted) password. The sole exception to this will be
the small number of implementations that support the Renewal operation, which
may be authorised purely through a signature, but presumably any
implementation recent enough to support Renewal also supports SHA-2. Any
legacy implementation that supports the historic core SCEP protocol would not
be affected.
The third reason is that SCEP uses the same key for encryption and signing, so
that even if an attacker were able to capture an outgoing Renewal request that
didn't include a password (in other words one that was only authorised through
a signature), forge the SHA-1 hash in real time, and forward the forged
request to the CA, they couldn't decrypt the returned certificate, which is
protected with the same key that was used to generate the signature. While
points out that SCEP uses unnecessary
cryptography in places, the additional level of security provided by the extra
crypto makes it immune to any issues with SHA-1.
This doesn't mean that SCEP implementations should continue to use SHA-1 in
perpetuity, merely that there's no need for a panicked switch to SHA-2.
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityGeneral
keywordThe Base16, Base32, and Base64 Data EncodingsCryptographic Message Syntax (CMS)Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentPKCS #9: Selected Object Classes and Attribute Types Version 2.0PKCS #10: Certification Request Syntax Specification Version 1.7Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileUniform Resource Identifiers (URI): Generic SyntaxCertificate Management over CMS (CMC)Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTPA Java implementation of the Simple Certificate Enrolment ProtocolInternet Key Exchange (IKEv2) ProtocolSecure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message SpecificationEnhanced Security Services for S/MIMEEnhanced Security Services (ESS) Update: Adding CertID Algorithm AgilityThe Transport Layer Security (TLS) Protocol Version 1.2IndependentRTFM, Inc.
This specification has spent more than seventeen years in the draft stage.
Its original goal, provisioning IPsec routers with certificates, has long
since changed to general device/embedded system/IoT use. To fit this role,
extra features were bolted on in a haphazard manner through the addition of a
growing list of appendices and by inserting additional, often conflicting,
paragraphs in various locations in the body text. Since existing features
were never updated as newer ones were added, the specification accumulated
large amounts of historical baggage over time. If OpenPGP was described as "a
museum of 1990s crypto" then the SCEP draft was its graveyard.
About five years ago the specification, which even at that point had seen only
sporadic re-posts of the existing document, was more or less abandoned by its
original sponsors. Due to its widespread use in large segments of the
industry, the specification was rebooted in 2015, cleaning up fifteen years
worth of accumulated cruft, fixing errors, clarifying ambiguities, and
bringing the algorithms and standards used into the current century (prior to
the update, the de-facto lowest-common denominator algorithms used for
interoperability were the insecure forty-year-old single DES and broken MD5
hash algorithms).
Note that although the text of the current specification has changed
significantly due to the consolidation of features and appendices into the
main document, the protocol it describes is identical on the wire to the
original (with the exception of the switch from single DES and MD5 to AES and
SHA-2). The only two changes introduced, the "SCEPStandard" indicator in
GetCACaps and the failInfoText attribute, are both optional values and would
be ignored by older implementations that don't support them, or can be omitted
from messages if they are found to cause problems.
Other changes include:
Resolved contradictions in the text, for example a requirement
given as a MUST in one paragraph and a SHOULD in the next, a MUST NOT
in one paragraph and a MAY a few paragraphs later, a SHOULD NOT
contradicted later by a MAY, and so on.Merged several later fragmentary addenda placed in appendices (for
example the handling of certificate renewal) with the body of the
text.Merged the SCEP Transactions and SCEP Transport sections, since the
latter mostly duplicated (with occasional inconsistencies) the
former.Updated the algorithms to ones dating from at least this
century.Did the same for normative references to other standards.Updated the text to use consistent terminology for the client and
CA rather than a mixture of client, requester, end entity, server,
certificate authority, certification authority, and CA.Corrected incorrect references to other standards, e.g.
IssuerAndSerial -> IssuerAndSerialNumber.Corrected errors such as a statement that when both signature and
encryption certificates existed, the signature certificate was used
for encryption.Condensed redundant discussions of the same topic spread across
multiple sections into a single location. For example the description
of intermediate CA handling previously existed in three different
locations, with slightly different reqirements in each one.Added a description of how pkiMessages were processed, which was
never made explicit in the original specification. This led to
creative interpretations that had security problems but were employed
anyway due to the lack of specific guidance on what to do.Relaxed some requirements that didn't serve any obvious purpose and
that major implementations didn't seem to be enforcing. For example
the requirement that the self-signed certificate used with a request
MUST contain a subject name that matched the one in the PKCS #10
request was relaxed to a SHOULD because a number of implementations
either ignored the issue entirely or at worst performed some minor
action like creating a log entry after which they continued
anyway.Removed discussion of the transactionID from the security
considerations, since the instructions there were directly
contradicted by the discussion of the use of the transactionID in
.Added a requirement that the signed message include the signing
certificate(s) in the signedData certificates field. This was
implicit in the original specification (without it, the message
couldn't be verified by the CA) and was handled by the fact that most
PKCS #7/CMS libraries do this by default, but was never explicitly
mentioned.Clarified sections that were unclear or even made no sense, for
example the requirement for a "hash on the public key" [sic] encoded
as a PrintableString.Renamed "RA certificates" to "intermediate CA certificates". The
original document at some point added mention of RA certificates
without specifying how the client was to determine that an RA was in
use, how the RA operations were identified in the protocol, or how it
was used. It's unclear whether what was meant was a true RA or merely
an intermediate CA, as opposed to the default practice of having
certificates issued directly from a single root CA certificate. This
update uses the term "intermediate CA certificates", since this seems
to have been the original intent of the text.Redid the PKIMessage diagram to match what was specified in CMS,
the original diagram omitted a number of fields and nested data
structures which meant that the diagram didn't match either the text
or the CMS specification.Removed the requirement for a CertPoll to contain a recipientNonce,
since CertPoll is a client message and will never be sent in response
to a message containing a senderNonce. See also the note in
.Clarified certificate renewal. These represent a capability that
was bolted onto the original protocol with (at best) vaguely-defined
semantics, including a requirement by the CA to guess whether a
particular request was a renewal or not. In response to developer
feedback that they either avoided renewal entirely because of this
uncertainty or hardcoded in particular behaviour on a per-CA basis,
this specification explicitly identifies renewal requests as such, and
provides proper semantics for them.Added the "SCEPStandard" keyword to GetCACaps to indicate that the
CA complies with the final version of the SCEP standard, since the
definition of what constitutes SCEP standards compliance has changed
significantly over the years.Added the optional failInfoText attribute to deal with the fact
that failInfo was incapable of adequately communicating to clients why
a certificate request operation had been rejected.Removed the discussion in the security considerations of revocation
issues, since SCEP doesn't support revocation as part of the
protocol.Clarified the use of nonces, which if applied as originally
specified would have made the use of polling in the presence of a lost
message impossible.Removed the discussion of generating a given transactionID by
hashing the public key, since this implied that there was some special
significance in the value generated this way. Since it was neither a
MUST nor a MAY, it was unsound to imply that servers could rely on the
value being generated a certain way. In addition it wouldn't work if
multiple transactions as discussed in were
initiated, since the deterministic generation via hashing would lead
to duplicate transactionIDs.Added examples of SCEP messages to give implementers something to
aim for.