Simple Certificate Enrolment ProtocolUniversity of AucklandDepartment of Computer ScienceAucklandNew Zealandpgut001@cs.auckland.ac.nzCisco Systems, Inc
Security Area
Internet-Draft
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a
Public Key Infrastructure (PKI) communication protocol which 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 now enjoys wide support in both client and server
implementations, as well as being relied upon by numerous other industry
standards that work with certificates.
Public key technology is widely available and increasingly widely deployed.
X.509 certificates serve as the basis for several standards-based security
protocols in the IETF, such as TLS, S/MIME, and and IKE/IPsec.
When an X.509 certificate is issued by other than the certificate subject (a
self-issued certificate), there typically is a need for a certificate
management protocol. Such a protocol enables a PKI client to request a
certificate, certificate renewal, or certificate update from a Certification
Authority (CA).
This specification defines a protocol, Simple Certificate Enrolment Protocol
(SCEP), for certificate management and certificate and CRL queries in a closed
environment. While widely deployed, this protocol omits some certificate
management features, e.g. certificate revocation transactions, which can
significantly 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 limited functionality, also
makes deployment relatively straightforward, so that it enjoys widespread
industry support and ready interoperability across a wide 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 protocol supports the following general operations:
CA public key distribution.Certificate enrolment.Certificate renewal/update.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
The Requester, or client ().The Server, a Certification Authority (CA) ().
The requester is sometimes called a "client" in this document. It is the
client of the SCEP exchange.
Before a requester can start a PKI transaction, it MUST have at least one
appropriate key pair for use when signing the SCEP pkiMessage ().
The message types, being based on CMS and PKCS #10, fully support algorithm agility but the
requester has to use a key type that is supported by the server.
Specifically, they must employ a PKC algorithm capable of both encryption and
signing. RSA is the only widely-used algorithm that has these properties.
A requester MUST have the following information locally configured:
The Certification Authority IP address or fully qualified
domain name.The Certification Authority HTTP CGI script path (this usually
has a default value, see ).The identifying information that is used for authentication of
the Certification Authority in ,
typically a certificate fingerprint. This information MAY be
obtained from the user, or presented to the end user for manual
authorization during the protocol exchange (e.g. the user
indicates acceptance of a fingerprint via a user-interface
element).
The requester MAY maintain multiple independent configurations appropriate for
multiple Certification Authorities. Doing so does not effect the protocol
operation and is not in scope of this document.
A SCEP Certification Authority (CA) is the entity that signs client
certificates. A certification authority MAY enforce any arbitrary policies
and apply them to certification requests. The certification authority MAY
reject any request. If the client has already been issued a certificate for
this keypair the server MAY return the previously created certificate. The
requester MUST NOT assume any of the fields in the certification request,
except for the public key, will be the same in the certificate issued.
The certification authority MAY include a cRLDistributionPoint extension in
every certificate it issues, make CRLs available via HTTP or LDAP, or answer CRL queries itself. In
the latter case it SHOULD be online at all times.
Since the client is expected to perform encryption and signature verification
using the CA certificate, the keyUsage extension in the CA certificate MUST
indicate that it is valid for digitalSignature and keyEncipherment use
alongside the usual CA usages of keyCertSign and/or cRLSign.
If a client times out from polling for a pending request it can resynchronize
by reissuing the original request with the original subject name, key, and
transactionID. The CA SHOULD return the status of the original transaction,
including the certificate if it was granted.
If the CA certificate(s) have not previously been acquired by the requester in
some other means, the requester MUST retrieve the CA certificate(s) before any
PKI operation () can be started.
Since no public key has yet been exchanged between the requester 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 transport protocol () MUST indicate which one is
returned.
The SCEP server CA certificate MAY be provided out-of-band to the SCEP
requester. Alternatively, the CA certificate fingerprint MAY be used to
authenticate a CA Certificate distributed by the GetCACert response () or via HTTP. The
fingerprint is created by calculating a SHA-1, SHA-256, or SHA-512 hash over
the whole CA certificate.
After the requester gets the CA certificate, it SHOULD authenticate the
certificate by comparing its fingerprint with the locally configured, out-of-
band distributed, identifying information. 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.
Because a long time can pass between queries from a requester to a CA and
because intermediate CA certificates can change over time, it is recommended
that a requester not store intermediate CA certificates. Instead, the
requester SHOULD retrieve the CA certificates before each operation.
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. This requirement is needed to prevent a man-in-the-middle (MITM)
attack, in which an adversary can manipulate the data as it travels between
the protocol participants and subvert the security of the protocol.
The communication between the requester and the certification authority are
secured using SCEP Secure Message Objects () 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 requester does not have an appropriate existing
certificate then a locally generated self-signed certificate MUST be
used. The self-signed certificate SHOULD use the same subject name
as in the PKCS #10 request. In this case the messageType is
PKCS10Req (see ).If the requesting system already has a certificate issued by the
SCEP server, and the server supports renewal (see ), that certificate SHOULD be used. In this
case the messageType is RenewalReq (see ).If the requesting system has no certificate issued by the new CA,
but has credentials from an alternate CA the certificate issued by
the alternate CA MAY be used. Policy settings on the new CA will
determine if the request can be accepted or not. This is useful when
enrolling with a new administrative domain using a certificate from
the old domain as credentials. In this case the messageType is
UpdateReq (see ).
Note that although the above text describes three 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 two are optional (see
).
During the certificate enrolment process, the requester MUST use the selected
certificate's key when signing the CMS envelope (see
). The server's CertResp then uses the same
certificate's public key when encrypting the response (see ).
When the certification authority creates the CMS
envelope containing the issued certificate, it SHOULD use the public key and
identifying information conveyed in the above included certificate. This will
inform the end entity of which private key is needed to open the envelope.
PKCS #10 specifies a PKCS
#9 challengePassword attribute to be sent as part of the enrolment
request. When utilizing the challengePassword, the server distributes a
shared secret to the requester which will uniquely associate the enrolment
request with the requester.
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
or update requests which 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 or update as per SHOULD omit the challengePassword but MAY send
the originally distributed password in the challengePassword attribute. In
the former case the SCEP CA MUST authenticate the request based on the
certificate used to sign the renewal or update request. In the latter case
the SCEP CA MAY use either the challengePassword or the previously issued
certificate (or both), depending on CA policy, to authenticate the request.
The SCEP server 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 requester's messages are
placed in the PENDING state until the CA operator authorizes or rejects them.
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 server MAY either reject
unauthorized certification requests or mark them for manual authorization
according to CA policy.
A requester 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 or update then a new certificate with
new validity dates can be issued, even though the old one is still valid, if
the CA policy permits. The server MAY automatically revoke the old client
certificate. To renew or update an existing certificate, the client uses the
RenewalReq or UpdateReq 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 certicate
using the old keypair.
If the CA returns a CertRep () message with status set
to PENDING, the requester enters into polling mode by periodically sending a
CertPoll () PKI message to the CA, until the CA
operator completes the manual authentication (approving or denying the
request).
In general, the requester will send a single PKCSReq/RenewalReq/UpdateReq
() message, followed by 0 or more CertPoll () messages, if polling mode is entered.
In general, the CA will send 0 or more CertRep ()
messages with status set to PENDING, followed by a single CertRep () with status set to either SUCCESS or FAILURE.
The requester state transitions during enrolment operation are indicated in
.
The certificate issue process starts at the state CERT-NONEXISTENT.
Sending a PKCSReq/RenewalReq/UpdateReq message changes the state to
CERT-REQ-PENDING. If there is no response, or sending is not possible, the
state reverts back to CERT-NONEXISTENT.
Receiving a CertRep message with pkiStatus set to SUCCESS changes the state to
CERT-ISSUED.
Receiving a CertRep message with pkiStatus set to FAILURE changes the state to
CERT-NONEXISTENT.
If the server sends back a CertRep message with pkiStatus set to PENDING, the
requester will keep polling by sending a CertPoll message to the server, until
either a CertRep message with status set to SUCCESS or FAILURE is received, or
the maximum number of polls has been exceeded.
If the maximum number of polls has been exceeded or a CertRep message with
pkiStatus set to FAILURE is received while in the CERT-REQ-PENDING state, the
end entity will transition to the CERT-NONEXISTENT state, and the SCEP client
can eventually initiate another enrolment request. It is important to note
that, as long as the requester does not change its subject name or keys, the
same transactionID may be used in the "new" transaction. This is important
because based on this transactionID, the certification authority can recognize
this as an existing transaction instead of a new one.
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 store access service, which
may be achieved via HTTP or LDAP.
To query a certificate from the certification authority, a requester sends a
request consisting of the certificate's issuer name and serial number. This
assumes that the requester 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.
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,
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 server SHOULD NOT support the GetCRL method because:
It does not scale well due to the unnecessary cryptography (see
).It requires the CA to be a high-availability service.Only limited information to determine the CRL scope is provided
(see ).
The message is sent to the SCEP server 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.
SCEP does not specify a method to request certificate revocation. In order to
revoke a certificate, the requester must contact the CA using a non-SCEP
defined mechanism.
At a minimum, all SCEP implementations compliant with this specification MUST
support 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.
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. The advantage of this technique over the conventional
transaction message format is that the signed transaction type information and
the status of the transaction can be determined prior to invoking security
handling procedures specific to the information portion being processed.
Some messages do not require enveloping, in which case the Enveloped-Data 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 ().
Note: 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.
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 contentType in contentInfo MUST be data ({pkcs-7 1}) as
defined in CMS.The signed content, if present (e.g. 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 (see
CMS as well as in this document).
At a minimum, all messages MUST contain the following authenticatedAttributes:
A transactionID attribute (see ).A messageType attribute (see ).A senderNonce attribute (see ).Any attributes required by CMS.
If the message is a response, it MUST also include the following
authenticatedAttributes:
A pkiStatus attribute (see ).A recipientNonce attribute (see ).
The following transaction attributes are encoded as authenticated attributes,
and are carried, as specified in CMS, 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 stringsenderNonceOCTET 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)}
The attributes are detailed in the following sections.
A PKI operation is a transaction consisting of the messages exchanged between
a requester and the server. The transactionID is a text string generated by
the client when starting a transaction. The client MUST generate a unique
string as the transaction identifier, which MUST be used for all PKI messages
exchanged for a given enrolment, encoded as a PrintableString.
One means of generating the transactionID is as a SHA-1, SHA-256, or SHA-512
hash of the public key value in the enrolment request when encoded as an X.509 SubjectPublicKeyInfo (in other words the exact
binary form in which it appears in both the request and the resulting
certificate) and then coverting it into a text string using base64 encoding or
ASCII hex digits. This allows the SCEP client to automatically generate the
same transactionID for any given public key. The SCEP protocol requires that
transactionIDs be unique, so that subsequent polling queries can be matched
with previous transactions.
When using the certificate query and CRL query messages defined in this
protocol, the transactionID is required so that the requester can match the
response message with the outstanding request message. For a non-enrolment
message (for example GetCert and GetCRL), the transactionID SHOULD be some
value unique to the client.
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 for renewal of an existing certificate.UpdateReq ("18") -- PKCS #10
certificate request for update of a certificate issued by a
different CA.PKCSReq ("19") -- PKCS #10
certificate request.CertPoll ("20") -- Certificate polling in manual enrolment.GetCert ("21") -- Retrieve a certificate.GetCRL ("22") -- Retrieve a CRL.
Undefined message types are treated as an error.
All response messages MUST include transaction status information, which is
defined as pkiStatus attribute:
SUCCESS ("0") -- request granted.FAILURE ("2") -- request rejected. When pkiStatus is
FAILURE, the failInfo attribute, as defined in , MUST also be present.PENDING ("3") -- request pending for manual approval.
Undefined pkiStatus attributes are treated as an error.
The failInfo attribute MUST contain one of the following failure reasons:
badAlg ("0") -- Unrecognized or unsupported algorithm
identifier.badMessageCheck ("1") -- integrity check 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 (see Section
3.1.1.6).badCertId ("4") -- No certificate could be identified
matching the provided criteria.
Undefined failInfo attributes are treated as an error.
The attributes of senderNonce and recipientNonce 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 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.
The information portion of a SCEP message is carried inside an Enveloped-Data
content type, as defined in CMS, with the following
restrictions:
contentType in encryptedContentInfo MUST be data ({pkcs-7 1})
as defined in CMS.encryptedContent MUST be the SCEP message being transported
(see ), and must match the
messageType authenticated Attribute in the pkiMessage.
The CMS content-encryption key is encrypted using
the public key of the recipient of the message, i.e. the CA public key (if
sent from the requester), or the requester public key (if sent as a reply to
the requester).
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 Certification Request. The certification 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, RenewalReq, or UpdateReq as appropriate.A senderNonce () attribute.
The pkcsPKIEnvelope for this message type is protected using the public key of
the recipient as detailed in , e.g. either the
CA public key.
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 this
message is a reply to. They are detailed in
and in .
In addition to the authenticatedAttributes required for a valid CMS, this pkiMessage MUST include the following
attributes:
The transactionID () attribute
copied from the request we are responding to.A messageType () attribute set to
CertRep.A senderNonce () attribute.A recipientNonce attribute () copied
from the senderNonce from the request that this is a response
to.A pkiStatus () set to the status of
the reply.
The pkcsPKIEnvelope for this message type is protected using the public key of
the recipient as detailed in . For example if
a self-signed certificate was used to send the original request then this
self-signed certificate's public key is used to encrypt the content-encryption
key of the SUCCESS response's pkcsPKIEnvelope.
Note that although it may appear that the senderNonce serves no purpose in
this message, it is required if the CertRep contains a PENDING status since
the nonce will be used in subsequent 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. The reply MUST NOT
contain a CRL.RenewalReqSame as PKCSReqUpdateReqSame 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. The
reply MUST NOT contain a CRL.GetCRLThe reply MUST contain the CRL in the crls field
of the Signed-Data. The reply MUST NOT contain a
certificate.
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 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 drafts. 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.
In addition to the authenticatedAttributes required for a valid CMS, this pkiMessage MUST include the following
attributes:
The same transactionID ()
attribute from the original PKCSReq/RenewalReq/UpdateReq
message.A messageType () attribute set to
CertPoll.A senderNonce () attribute.A recipientNonce attribute () copied
from the senderNonce from the request that this is a response
to.
The messageData for this type consists of an IssuerAndSerialNumber as defined
in CMS which uniquely identifies the certificate
being requested.
In addition to the authenticatedAttributes required for a valid CMS, this pkiMessage MUST include the following
attributes:
A transactionID () attribute.A messageType () attribute set to
GetCert.A senderNonce () attribute.
A self-signed certificate MAY be used in the signed envelope. This enables
the requester to request their own certificate if they were unable to store it
previously.
The messageData for this type consists of a IssuerAndSerialNumber as defined
in CMS containing the issuer name and serial number
of the certificate whose revocation status is being checked.
In addition to the authenticatedAttributes required for a valid CMS, this pkiMessage MUST include the following
attributes:
A transactionID () attribute.A messageType () attribute set to
GetCRL.A senderNonce () attribute.CMS includes a degenerate case of the CMS 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 will be
included in the 'crls' field of the Signed-Data.
In order to provide support for future enhancements to the protocol, CAs
SHOULD implement the GetCACaps message to allow clients to query which
functionality is available from the CA.
with the message components as described in . The
response is a list of text capabilities, as defined in . CA servers SHOULD support the GetCACaps message and
MUST support it when they implement any extended functonality beyond the
mandatory-to-implement basics .
The response for a GetCACaps message is a list of CA
capabilities, in plain text, separated by <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"PKIOPeration messages may be 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."Update"CA Supports the Update CA operation.
The client SHOULD use SHA-256 or SHA-512 in preference to SHA-1 hashing, and
AES in preference to triple DES if they are supported by the CA.
Announcing some of these capabilities is redundant since they're required as
mandatory-to-implement functionality (see ), 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 server MUST use the texual case specified here, but clients SHOULD ignore
the textual case when processing this message. 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 the SCEP server SHOULD
return an empty message. A server 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. This means that the equivalent of GetCACaps must be
performed through server fingerprinting, which can be done using the ID string
"Microsoft-IIS").
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore
the Content-type, as older server implementations of SCEP may send various
Content-types.
This means that the CA supports modern crypto algorithms, the GetNextCACert
message, and allows PKIOperation messages (PKCSReq/RenewalReq/UpdateReq,
GetCert, CertPoll, ...) to be sent using HTTP POST.
This section describes the SCEP Transactions, without explaining the
transport. The transport of each message is discussed in . Some of the transaction-requests have no data to send,
i.e. the only data is the message-type itself (e.g. a GetCACert message has no
additional data).
In this section, each SCEP transaction is specified in terms of the complete
messages exchanged during the transaction.
To get the CA certificate(s), the requester sends a GetCACert message to the
server. There is no request data associated with this message (see ).
The server MUST indicate which response it is sending via the transport
protocol used (see ). If the requester does
not have a certificate path to a trust anchor certificate, the SHA-1, SHA-256,
or SHA-512 fingerprint of the returned CA certificate (communicated via out-
of- band means) may be used to verify it.
All returned certificates MUST conform to PKIX.
If the server does not have any intermediate CA certificates, the response
consists of a single X.509 CA certificate.
If the server has intermediate CA certificates, the response consists of a
degenerate certificates-only CMS Signed-Data () containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s).
A PKCSReq/RenewalReq/UpdateReq () message is used to
perform a certificate enrolment, renewal, or update transaction.
The reply MUST be a CertRep () message sent back from
the server, indicating SUCCESS, FAILURE, or PENDING.
Precondition: Both the requester and the certification authority have
completed their initialization process. The requester has already been
configured with the CA certificate.
Postcondition: The requester receives the certificate, the request is
rejected, or the request is pending. A pending response might indicate that
manual authentication is necessary.
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 requester).
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.
If the the CA is configured to manually authenticate the requester, a CertRep
() message with pkiStatus set to PENDING MAY be
returned. The CA MAY return a PENDING for other reasons.
Triggered by a CertRep () with pkiStatus set to
PENDING, a requester will enter the polling state by periodically sending
CertPoll messages () to the server, 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.
CertPoll messages exchanged during the polling period MUST carry the same
transactionID attribute as the previous PKCSReq/RenewalReq/UpdateReq. A
server receiving a CertPoll for which it does not have a matching
PKCSReq/RenewalReq/UpdateReq MUST ignore this request.
Since at this time the certificate has not been issued, the requester can only
use its own subject name (which was contained in the original PKCS# 10 sent
via PKCSReq/RenewalReq/UpdateReq) to identify the polled certificate request.
In theory there can be multiple outstanding requests from one requester (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 it's safer for
the requester to not have multiple requests outstanding at any one time, since
this tends to confuse some servers.
PreCondition: The requester has received a CertRep with pkiStatus set to
PENDING.
PostCondition: The requester has either received a valid response, which could
be either a valid certificate (pkiStatus = SUCCESS), or a FAILURE message, or
the polling period times out.
The response messages for CertPoll are the same as in .
A requester can query an issued certificate from the SCEP server, as long as
the requester knows the issuer name and the issuer assigned certificate serial
number.
This transaction consists of one GetCert () message
sent to the server by a requester, and one CertRep ()
message sent back from the server.
PreCondition: The certification authority has issued the queried certificate
and the issuer assigned serial number is known.
PostCondition: Either the certificate is sent back or the request is rejected.
In this case, the CertRep from the server is same as in Section , except that the server will only either grant
the request (SUCCESS) or reject the request (FAILURE).
Clients can request a CRL from the SCEP server as described in .
PreCondition: The certification authority certificate has been downloaded to
the end entity.
PostCondition: CRL sent back to the requester.
The CRL is sent back to the requester 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 the CA certificate expires all certificates that have been signed by it
are no longer valid. CA key rollover provides a mechanism by which the server
MAY distribute a new CA certificate which is valid in the future; when the
current certificate has expired. 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. There is no
request data associated with this message (see ).
Clients MUST store the not-yet-valid CA certificate, and any not-yet-valid
client certificates obtained, until such time that they are valid, at which
point clients switch over to using the newly valid certificates.
The response consists of a Signed-Data CMS, signed
by the current CA signing key. Clients MUST validate the signature on the the
Signed-Data CMS before accepting any of its
contents.
The content of the Signed-Data CMS message is a
degenerate certificates-only Signed-Data () message
containing the new CA certificate(s) as defined in , to be used when the current CA certificate
expires.
If the CA does not have the rollover certificate(s) it MUST reject the
request. It SHOULD also remove the GetNextCACert setting from the
capabilities until it does have rollover certificates.
If there are any intermediate CA certificates in this response, clients MUST
check that these certificates are signed by the CA, and MUST check
authorization of these intermediate CA certificates (see ).
HTTP is used as the transport protocol for SCEP
Message Objects.
SCEP uses the HTTP "GET" and "POST" messages to exchange information with the
CA. The following defines the syntax of a HTTP GET and POST messages sent
from a requester to a certification authority server:
where:
CGI-PATH defines the actual CGI 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, though the CA may ignore CGI-PROG and use only the
CGI-PATH, or ignore both if it's not issuing certificates via a web
server. Typically, setting CGI-PATH/CGI-PROG to
"/cgi-bin/pkiclient.exe" will satisfy most servers.OPERATION depends on the SCEP transaction and is defined in the
following sections.MESSAGE depends on the SCEP transaction and is defined in the
following sections.
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 it, any of the CMS-encoded SCEP messages SHOULD be sent via HTTP POST
instead of HTTP GET. This is allowed for any SCEP message except GetCACert,
GetNextCACert, or 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 your client or server 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 typically to move to 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
bas64 encoded.
For each GET or POST operation, the CA server MUST return a Content-Type and
appropriate response data, if any.
This section describes the OPERATION and MESSAGE values for SCEP exchanges.
The OPERATION MUST be set to "GetCACert".
The response for GetCACert is different between the case where the CA directly
communicates with the requester during the enrolment, and the case where an
intermediate CA exists and the requester communicates with this CA during the
enrolment.
The response will have a Content-Type of "application/x-x509-ca-cert".
The body of this response consists of an X.509 CA certificate, as defined in
:
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 SCEP drafts, no special meaning should be attached to the label itself.
The body of this response consists of a degenerate certificates-only CMS Signed-Data () message
containing both CA and intermediate CA certificates, as defined in :
The OPERATION MAY be set to "PKIOperation". When used with HTTP POST, the
only OPERATION possible is "PKIOperation", so many servers don't check this
values or even notice its absence.
The MESSAGE consists of a PKCSReq, RenewalReq, or UpdateReq SCEP message.
When implemented using HTTP POST this might look as follows:
When implemented using HTTP GET this might look as follows:
The response will have a Content-Type of "application/x-pki-message".
The body of this response consists of a CertRep SCEP message defined in . The following is an example of the response:
The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a
CertPoll SCEP message.
The body of this response consists of a CertRep SCEP message defined in .
The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a
GetCert SCEP message.
The body of this response consists of a CertRep SCEP message defined
in .
The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a GetCRL
SCEP message.
The body of this response consists of a CertRep SCEP message defined in .
The OPERATION MUST be set to "GetNextCACert".
The response will have a Content-Type of "application/x-x509-next-ca-cert".
The body of this response consists of a Signed-Data
CMS, as defined in . (This is
similar to the GetCert response but does not include any of the attributes
defined in ).
The editor would like to thank all the previous editors, authors and
contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy
Nourse, Max Pritikin, Jan Vilhuber, etc 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.
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.
This memo includes no request to IANA.
The security goals of SCEP are that no adversary can:
Subvert the public key/identity binding from that intended.Discover the identity information in the enrolment requests and
issued certificates.
Here an adversary is any entity other than the requester and the CA
participating in the protocol. The adversary is computationally limited, but
that can manipulate data during transmission (that is, can act as a MITM).
The precise meaning of 'computationally limited' depends on the implementer's
choice of one-way hash functions and cryptographic algorithms.
The first and second goals are 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, as specified in , and the SCEP
client's public key is authenticated through manual or pre-shared secret
authentication, as specified in .
The motivation of the first security goal is straightforward. The motivation
for the second security goal is to protect the identity information in the
enrolment requests and issued certificates. Subsequent protocols can use the
certificate in ways that either expose the identity information, or protect
it, depending on the security requirements of those protocols. The motivation
for the third security goal is to protect the SCEP clients from denial of
service attacks.
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) certificate
(and CRL) signing exclusively, rather than data signing or encryption. The
SCEP protocol, however, uses the CA private key to both encrypt and sign CMS transport messages. This is generally considered
undesirable, as it widens the possibility of an implementation weakness, and
provides:
Another place that the private key must be used (and hence is
slightly more vulnerable to exposure).Another place where a side channel attack (say, timing or power
analysis) might be used.Another place that the attacker might somehow insert their own
data and get it signed by the CA's private key (note that this
issue is purely theoretical, since the CMS data signed by the CA
is nothing remotely like a certificate and couldn't be passed off
as such).
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.
If the challengePassword is used to automatically authenticate an enrolment
request, it is recommended that some form of one-time password be used to
minimize damage in the event the data is compromised.
CAs SHOULD NOT rely on the transactionID to be correct or as specified in this
document. Requesters with buggy software might add additional undetected
duplicate requests to the CA's queue. A well-written CA should never assume
the data from a requester is well-formed.
In order to detect replay attacks, both sides need to maintain state
information sufficient to detect an unexpected nonce value.
The GetCACaps response is not signed. This allows an attacker to perform
downgrade attacks on the cryptographic capabilities of the client/CA exchange.
Some of the SCEP exchanges use signing and encryption operations that are not
necessary. In particular the GetCert and GetCRL exchanges are encrypted and
signed in both directions. The information requested is public and thus
signing the requests is of questionable value but also CRLs and Certificates,
i.e. the respective responses, are already signed by the CA and can be
verified by the recipient without requiring additional signing and encryption.
This may affect performance and scalability of the CA and could be used as an
attack vector on the CA (though not an anonymous one). The use of CRLDPs as
well as other ways of retrieving certificates such as HTTP access and LDAP are
recommended for CRL access.
GetNextCACert depends on a 'flag moment' at which every client in the PKI
infrastructure switches from the current CA certificate (and client
certificate) to the new CA certificate and client certificates. Proper
monitoring of the network infrastructure can ensure that this will proceed as
expected but any errors in processing or implementation can result in a
failure of the PKI infrastructure.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University
General
keywordThe Base16, Base32, and Base64 Data EncodingsCryptographic Message Syntax (CMS)Hypertext Transfer Protocol -- HTTP/1.1PKCS #9: Selected Object Classes and Attribute Types Version 2.0PKCS #10: Certification Request Syntax Specification Version 1.7PKCS #10: Certification Request Syntax Specification Version 1.7Uniform 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 HTTPInternet Key Exchange (IKEv2) ProtocolSecure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message SpecificationThe Transport Layer Security (TLS) Protocol Version 1.2IndependentRTFM, Inc.
SCEP state transitions are indexed by the transactionID attribute. The design
goal is to ensure the synchronization between the CA and the requester under
various error situations.
Each enrolment transaction is uniquely associated with a transactionID
(carried in the transactionID signed attribute (see ). Because the enrolment transaction could be
interrupted by various errors, including network connection errors or client
reboot, the SCEP client generates a fixed transaction identifier as specified
in which is included in the
PKCSReq/RenewalReq/UpdateReq. If the CA returns a response of PENDING, the
requester will poll by periodically sending a CertPoll with the same
transaction identifier until either a response other than PENDING is obtained
or the configured maximum time has elapsed. This mechanism retains the same
transaction identifier throughout the enrolment transaction.
If the client times out or reboots, the client administrator will
start another transaction with the same key pair. The second enrolment will
have the same transactionID. At the server side, instead of accepting the
PKCSReq/RenewalReq/UpdateReq as a new request, it can respond as if another
CertPoll message had been sent with that transaction ID. The second
PKCSReq/RenewalReq/UpdateReq should be taken as a resynchronization message to
allow the process to resume as the same transaction.
The following gives several examples of client to CA transactions.
Client actions are indicated in the left column, CA actions are indicated in
the right column. A blank action signifies that no message was received.
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."
This specification has spent more than fifteen years in the draft stage. Its
original goal, provisioning IPsec routers with RSA 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 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 forty-year-old single DES and broken MD5 hash algorithms).
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 and update) with the body
of the text.Updated the algorithms to ones dating from at least this
century.Did the same for normative references to other standards.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.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.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 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.Clarified certificate renewal and update. These represent a
capability that was bolted onto the original protocol with (at best)
vaguely-defined semantics, including a requirement by the server to
guess whether a particular request was a renewal or not (updates were
even more vaguely defined). In response to developer feedback that
they either avoided renewal/update entirely because of this
uncertainty or hardcoded in particular behaviour on a per-server
basis, this specification explicitly identifies renewal and update
requests as such, and provides proper semantics for both.
Note that this is still a work in progress due to the lack of clarity
of the original spec in this area, see some of the questions inline
with the text.Removed the discussion in the security considerations of revocation
issues, since SCEP doesn't support revocation.