rfc8894xml2.original.xml   rfc8894.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocdepth='5'?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="info" consensus="true" ipr="pre5378Trust200902"
docName="draft-gutmann-scep-16" number="8894" obsoletes="" updates=""
xml:lang="en" tocInclude="true" tocDepth="5" symRefs="true"
sortRefs="true" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 2.42.0 -->
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-gutmann-scep-16">
<!-- ======================================================================== -->
<front> <front>
<title abbrev="SCEP">Simple Certificate Enrolment Protocol</title> <title abbrev="SCEP">Simple Certificate Enrolment Protocol</title>
<seriesInfo name="RFC" value="8894" />
<author initials="P." surname="Gutmann" fullname="Peter Gutmann"> <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
<organization abbrev="University of Auckland">University of Auckland</orga nization> <organization abbrev="University of Auckland">University of Auckland</orga nization>
<address> <address>
<postal> <postal>
<street>Department of Computer Science</street> <street>Department of Computer Science</street>
<city>Auckland</city> <city>Auckland</city>
<country>New Zealand</country> <country>New Zealand</country>
</postal> </postal>
<email>pgut001@cs.auckland.ac.nz</email> <email>pgut001@cs.auckland.ac.nz</email>
</address> </address>
</author> </author>
<date year="2020"/> <date month="September" year="2020" />
<area>Security Area</area> <area>Security Area</area>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t> <t>
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a This document specifies the Simple Certificate Enrolment Protocol (SCEP), a
PKI protocol that leverages existing technology by using CMS (formerly known PKI protocol that leverages existing technology by using Cryptographic Message
as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment Syntax (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 protocol sponsored by Cisco Systems, which enjoys wide support in both client
and server implementations, as well as being relied upon by numerous other and server implementations, as well as being relied upon by numerous other
industry standards that work with certificates. industry standards that work with certificates.
</t> </t>
</abstract> </abstract>
<!--
Status of this Memo
<t>
This document is not an Internet Standards Track specification; it is
published for informational purposes.
</t>
<t>
This document is a product of the Internet Engineering Task Force (IETF). The
consensus of the IETF community is that this document should be published
because it describes a protocol that is in wide use. However, the design of
the protocol itself does not represent the consensus of the IETF community.
The document has received public review and has been approved for publication
by the Internet Engineering Steering Group (IESG). Not all documents approved
by the IESG are a candidate for any level of Internet Standard; see Section 2
of RFC 7841.
</t>
</front> </front>
<!-- ======================================================================== -->
<middle> <middle>
<!-- ====================================================================== <section anchor="introduction" numbered="true" toc="default">
--> <name>Introduction</name>
<section anchor="introduction" title="Introduction">
<t> <t>
X.509 certificates serve as the basis for several standardised security X.509 certificates serve as the basis for several standardised security
protocols such as <xref target="TLS">TLS</xref>, <xref target="SMIME"> protocols such as <xref target="RFC8446" format="default">TLS</xref>, <xref
S/MIME</xref>, and <xref target="IKEv2">IKE/IPsec</xref>. When an X.509 target="RFC8551" format="default">S/MIME</xref>, and <xref target="RFC7296"
certificate is issued there typically is a need for a certificate management format="default">IKE/IPsec</xref>. 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 protocol to enable a PKI client to request or renew a certificate from a
Certificate Authority (CA). This specification defines a protocol, Simple Certificate Authority (CA). This specification defines a protocol, the Simple
Certificate Enrolment Protocol (SCEP), for certificate management and Certificate Enrolment Protocol (SCEP), for certificate management and
certificate and CRL queries. certificate and CRL queries.
</t> </t>
<t> <t>
The SCEP protocol supports the following general operations: The SCEP protocol supports the following general operations:
</t> </t>
<ul spacing="compact">
<li>CA public key distribution</li>
<li>Certificate enrolment and issue</li>
<li>Certificate renewal</li>
<li>Certificate query</li>
<li>CRL query</li>
</ul>
<t> <t>
<list style="symbols"> SCEP makes extensive use of <xref target="RFC5652" format="default">CMS</xref>
and <xref target="RFC2986" format="default">PKCS #10</xref>.
<t>CA public key distribution.</t>
<t>Certificate enrolment and issue.</t>
<t>Certificate renewal.</t>
<t>Certificate query.</t>
<t>CRL query.</t>
</list>
</t> </t>
<t>
SCEP makes extensive use of <xref target="CMS">CMS</xref> and <xref
target="PKCS10">PKCS #10</xref>.
</t> <section anchor="mustshouldmay" numbered="true" toc="default">
<section anchor="mustshouldmay" title="Conventions Used in This Document"> <name>Conventions Used in This Document</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in <xref target="RFC2119"/> and <xref target="RFC8174 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
.</t> are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174
"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document uses the Augmented Backus-Naur Form (ABNF) notat <t>This document uses the Augmented Backus-Naur Form (ABNF) notation
ion as specified in <xref target="RFC5234" format="default"/> for defining f
as specified in <xref target="ABNF"/> for defining formal syntax of ormal syntax of
commands. Non-terminals not defined in <xref target="ABNF"/> a commands. Non-terminals not defined in <xref target="RFC5234" format="de
re fault"/> are
defined in <xref target="HTTP-GET-POST"/>.</t> defined in <xref target="HTTP-GET-POST" format="default"/>.</t>
</section> </section>
</section> </section>
<!-- ======================================================================
--> <section anchor="overview" numbered="true" toc="default">
<section anchor="overview" title="SCEP Overview"> <name>SCEP Overview</name>
<t> <t>
This section provides an overview of the functionality of SCEP. This section provides an overview of the functionality of SCEP.
</t> </t>
<section anchor="overview-entities" title="SCEP Entities"> <section anchor="overview-entities" numbered="true" toc="default">
<name>SCEP Entities</name>
<t> <t>
The entity types defined in SCEP are a client requesting a certificate and a The entity types defined in SCEP are a client requesting a certificate and a
Certificate Authority (CA) that issues the certificate. These are described Certificate Authority (CA) that issues the certificate. These are described
in the following sections. in the following sections.
</t> </t>
<section anchor="overview-client" title="Client"> <section anchor="overview-client" numbered="true" toc="default">
<name>Client</name>
<t> <t>
A client MUST have the following information locally configured: A client <bcp14>MUST</bcp14> have the following information locally configured:
</t> </t>
<t> <ol type="1">
<li>The CA's fully qualified domain name or IP address.</li>
<list style="numbers"> <li>Any identification and/or authorisation information required by
<t>The CA's fully qualified domain name or IP address.</t
>
<t>Any identification and/or authorisation information re
quired by
the CA before a certificate will be issued, as described in the CA before a certificate will be issued, as described in
<xref target="PKCSReq"/>.</t> <xref target="PKCSReq" format="default"/>.</li>
<li>The identifying information that is used for authentication of
<t>The identifying information that is used for authentic the CA in <xref target="GetCACert-resp" format="default"/
ation of >, typically a certificate
the CA in <xref target="GetCACert-resp"/>, typically a ce fingerprint.</li>
rtificate </ol>
fingerprint.</t> </section>
<section anchor="overview-ca" numbered="true" toc="default">
</list> <name>Certificate Authority</name>
</t>
</section>
<section anchor="overview-ca" title="Certificate Authority">
<t> <t>
A SCEP CA is the entity that signs client certificates. A CA may enforce A SCEP CA is the entity that signs client certificates. A CA may enforce
policies and apply them to certificate requests, and may reject a request for policies and apply them to certificate requests, and it may reject a request for
any reason. any reason.
</t> </t>
<t>
<t>
Since the client is expected to perform signature verification and optionally Since the client is expected to perform signature verification and optionally
encryption using the CA certificate, the keyUsage extension in the CA encryption using the CA certificate, the keyUsage extension in the CA
certificate MUST indicate that it is valid for digitalSignature and certificate <bcp14>MUST</bcp14> indicate that it is valid for digitalSignature a nd
keyEncipherment (if the key is to be used for en/decryption) alongside the keyEncipherment (if the key is to be used for en/decryption) alongside the
usual CA usages of keyCertSign and/or cRLSign. usual CA usages of keyCertSign and/or cRLSign.
</t> </t>
</section> </section>
</section> </section>
<section anchor="overview-cert-dist" title="CA Certificate Distribution"> <section anchor="overview-cert-dist" numbered="true" toc="default">
<t> <name>CA Certificate Distribution</name>
<t>
If the CA certificate(s) have not previously been acquired by the client 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 through some other means, the client <bcp14>MUST</bcp14> retrieve them before an
operation (<xref target="message-obj"/>) can be started. Since no public key y PKI
operation (<xref target="message-obj" format="default"/>) can be started. Since
no public key
has yet been exchanged between the client and the CA, the messages cannot be has yet been exchanged between the client and the CA, the messages cannot be
secured using CMS, and the CA certificate request and response data is instead secured using CMS, and the CA certificate request and response data is instead
transferred in the clear. transferred in the clear.
</t> </t>
<t> <t>
If an intermediate CA is in use, a certificates-only CMS SignedData message
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. with a certificate chain consisting of all CA certificates is returned.
Otherwise the CA certificate itself is returned. Otherwise, the CA certificate itself is returned.
</t> </t>
<t> <t>
The CA certificate <bcp14>MAY</bcp14> be provided out of band to the client. Al
The CA certificate MAY be provided out-of-band to the client. Alternatively, ternatively,
the CA certificate fingerprint MAY be used to authenticate a CA Certificate the CA certificate fingerprint <bcp14>MAY</bcp14> be used to authenticate a CA c
distributed by the GetCACert response (<xref target="GetCACert"/>) or via ertificate
<xref target="HTTP-certstore">HTTP certificate-store access</xref>. The distributed by the GetCACert response (<xref target="GetCACert" format="default"
/>) or via
<xref target="RFC4387" format="default">HTTP certificate-store access</xref>. T
he
fingerprint is created by calculating a SHA-256 hash over the whole CA 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 certificate. (For legacy reasons, a SHA-1 hash may be used by some
implementations). implementations.)
</t> </t>
<t> <t>
After the client gets the CA certificate, it SHOULD authenticate it in some After the client gets the CA certificate, it <bcp14>SHOULD</bcp14> authenticate
manner unless this is deemed unnecessary, for example because the device is it in some
being provisioned inside a trusted environment. For example it could compare manner unless this is deemed unnecessary, for example, because the device is
its fingerprint with locally configured, out-of-band distributed, identifying being provisioned inside a trusted environment. For example, the client could c
ompare
the certificate's fingerprint with locally configured, out-of-band distributed,
identifying
information, or by some equivalent means such as a direct comparison with a information, or by some equivalent means such as a direct comparison with a
locally-stored copy of the certificate. locally stored copy of the certificate.
</t> </t>
<t> <t>
Intermediate CA certificates, if any, are signed by a higher-level CA so there 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. Since is no need to authenticate them against the out-of-band data. Since
intermediate CA certificates are rolled over more frequently than long-lived intermediate CA certificates are rolled over more frequently than long-lived
top-level CA certificates, clients MUST verify intermediate-level CA top-level CA certificates, clients <bcp14>MUST</bcp14> verify intermediate-level CA
certificates before use during protocol exchanges in case the intermediate CA certificates before use during protocol exchanges in case the intermediate CA
certificate has expired or otherwise been invalidated. certificate has expired or otherwise been invalidated.
</t> </t>
<t> <t>
When a CA certificate expires, certificates that have been signed by it may no 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 longer be regarded as valid. CA key rollover provides a mechanism by which
the CA can distribute a new CA certificate which is valid in the future once the CA can distribute a new CA certificate that will be valid in the future once
the current certificate has expired. This is done via the GetNextCACert the current certificate has expired. This is done via the GetNextCACert
message (section <xref target="get-next-CA"/>). message (<xref target="get-next-CA" format="default"/>).
</t> </t>
</section> </section>
<section anchor="overview-req-auth" title="Client authentication"> <section anchor="overview-req-auth" numbered="true" toc="default">
<name>Client Authentication</name>
<t> <t>
As with every protocol that uses public-key cryptography, the association As with every protocol that uses public-key cryptography, the association
between the public keys used in the protocol and the identities with which between the public keys used in the protocol and the identities with which
they are associated must be authenticated in a cryptographically secure they are associated must be authenticated in a cryptographically secure
manner. Communications between the client and the CA are secured using SCEP manner. Communications between the client and the CA are secured using SCEP
Secure Message Objects as explained in <xref target="message-obj"/>, which Secure Message Objects as explained in <xref target="message-obj" format="defaul t"/>, which
specifies how CMS is used to encrypt and sign the data. In order to perform 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: the signing operation, the client uses an appropriate local certificate:
</t> </t>
<t> <ol type="1">
<li>If the client does not have an appropriate existing certificate,
<list style="numbers"> then a locally generated self-signed certificate <bcp14>MUST</b
cp14> be used. The
<t>If the client does not have an appropriate existing certific keyUsage extension in the certificate <bcp14>MUST</bcp14> indic
ate ate that it is valid
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 for digitalSignature and keyEncipherment (if available). The
self-signed certificate SHOULD use the same subject name and ke self-signed certificate <bcp14>SHOULD</bcp14> use the same subj
y as ect name and key as
in the PKCS #10 request. In this case the messageType is PKCSR in the PKCS #10 request. In this case, the messageType is PKCS
eq Req
(see <xref target="messageType"/>).</t> (see <xref target="messageType" format="default"/>).</li>
<li>If the client already has a certificate issued by the SCEP CA, and
<t>If the client already has a certificate issued by the SCEP C the CA supports renewal (see <xref target="overview-cert-enrol"
A and format="default"/>),
the CA supports renewal (see <xref target="overview-cert-enrol" that certificate <bcp14>SHOULD</bcp14> be used. In this case, t
/>), he messageType is
that certificate SHOULD be used. In this case the messageType i RenewalReq (see <xref target="messageType" format="default"/>).
s </li>
RenewalReq (see <xref target="messageType"/>).</t> <li>Alternatively, if the client has no certificate issued by the
SCEP CA but has credentials from an alternate CA, then the
<t>Alternatively, if the client has no certificate issued by th certificate issued by the alternate CA <bcp14>MAY</bcp14> be us
e ed in a renewal
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. The SCEP CA's policy will determin e request as described above. The SCEP CA's policy will determin e
whether the request can be accepted or not.</t> whether the request can be accepted or not.</li>
</ol>
</list>
</t>
<t> <t>
Note that although the above text describes several different types of Note that although the above text describes several different types of
operations, for historical reasons most implementations always apply the first operations, for historical reasons, most implementations always apply the first
one even if an existing certificate already exists. For this reason support 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 for the first case is mandatory while support for the latter ones are optional
(see <xref target="MTI"/>). (see <xref target="MTI" format="default"/>).
</t> </t>
<t> <t>
During the certificate-enrolment process, the client <bcp14>MUST</bcp14> use
During the certificate enrolment process, the client MUST use the selected the selected certificate's key when signing the CMS envelope (see <xref
certificate's key when signing the CMS envelope (see <xref target="message-obj" format="default"/>). This certificate will be either the
target="message-obj"/>). This certificate will be either the self-signed one self-signed one matching the PKCS #10 request or the CA-issued one used to
matching the PKCS #10 request or the CA-issued one used to authorise a authorise a renewal, and it <bcp14>MUST</bcp14> be included in the signedData
renewal, and MUST be included in the signedData certificates field (possibly certificates field (possibly as part of a full certificate chain). If the key
as part of a full certificate chain). If the key being certified allows being certified allows encryption, then the CA's CertResp will use the same
encryption then the CA's CertResp will use the same certificate's public key certificate's public key when encrypting the response.
when encrypting the response.
</t> </t>
<t> <t>
Note that, in the case of renewal operations, this means that the request will
Note that in the case of renewal operations this means that the request will be signed and authenticated with the key in the previously issued certificate
be signed and authenticated with the key in the previously-issued certificate
rather than the key in the PKCS #10 request, and the response may similarly be rather than the key in the PKCS #10 request, and the response may similarly be
returned encrypted with the key in the previously-issued certificate. This returned encrypted with the key in the previously issued certificate. This
has security implications, see <xref target="security-no-pop"/>. has security implications; see <xref target="security-no-pop" format="default"/>
.
</t> </t>
</section> </section>
<section anchor="overview-enrol-auth" title="Enrolment authorisation">
<section anchor="overview-enrol-auth" numbered="true" toc="default">
<name>Enrolment Authorisation</name>
<t> <t>
<xref target="PKCS10">PKCS #10</xref> specifies a <xref target="PKCS9">PKCS <xref target="RFC2986" format="default">PKCS #10</xref> specifies a <xref target ="RFC2985" format="default">PKCS
#9</xref> challengePassword attribute to be sent as part of the enrolment #9</xref> challengePassword attribute to be sent as part of the enrolment
request. When utilizing the challengePassword, the CA distributes a shared request. When utilising the challengePassword, the CA distributes a shared
secret to the client which will be used to authenticate the request from the secret to the client, which will be used to authenticate the request from the
the client. It is RECOMMENDED that the challengePassword be a one-time client. It is <bcp14>RECOMMENDED</bcp14> that the challengePassword be a
one-time
authenticator value to limit the ability of an attacker who can capture the authenticator value to limit the ability of an attacker who can capture the
authenticator from the client or CA to re-use it to request further authenticator from the client or CA and reuse it to request further
certificates. certificates.
</t> </t>
<t> <t>
Inclusion of the challengePassword by the SCEP client is RECOMMENDED, however Inclusion of the challengePassword by the SCEP client is
<bcp14>RECOMMENDED</bcp14>; however,
its omission allows for unauthenticated authorisation of enrolment requests its omission allows for unauthenticated authorisation of enrolment requests
(which may, however, require manual approval of each certificate issue if (which may, however, require manual approval of each certificate issue if
other security measures to control issue aren't in place, see below). other security measures to control issue aren't in place; see below).
Inclusion is OPTIONAL for renewal requests that are authenticated by being Inclusion is <bcp14>OPTIONAL</bcp14> for renewal requests that are authenticated
by being
signed with an existing certificate. The CMS envelope protects the privacy of signed with an existing certificate. The CMS envelope protects the privacy of
the challengePassword. the challengePassword.
</t> </t>
<t> <t>
A client that is performing certificate renewal as per <xref A client that is performing certificate renewal as per <xref target="overview-ce
target="overview-cert-enrol"/> SHOULD omit the challengePassword but MAY send rt-enrol" format="default"/> <bcp14>SHOULD</bcp14> omit the challengePassword bu
t <bcp14>MAY</bcp14> send
the originally distributed shared secret in the challengePassword attribute. the originally distributed shared secret in the challengePassword attribute.
The SCEP CA MAY use the challengePassword in addition to the previously issued The SCEP CA <bcp14>MAY</bcp14> authenticate the request using the
certificate that signs the request to authenticate the request. The SCEP CA challengePassword in addition to the previously issued certificate that signs
MUST NOT attempt to authenticate a client based on a self-signed certificate the request. The SCEP CA <bcp14>MUST NOT</bcp14> attempt to authenticate a
unless it has been verified through out-of-band means such as a certificate client based on a self-signed certificate unless it has been verified through
fingerprint. out-of-band means such as a certificate fingerprint.
</t> </t>
<t> <t>
To perform the authorisation in manual mode the client's request is placed in To perform the authorisation in manual mode, the client's request is placed in
the PENDING state until the CA operator authorises or rejects it. Manual the PENDING state until the CA operator authorises or rejects it. Manual
authorisation is used when the client has only a self-signed certificate that authorisation 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 hasn't been previously authenticated by the CA and/or a challengePassword is
not available. The SCEP CA MAY either reject unauthorised requests or mark not available. The SCEP CA <bcp14>MAY</bcp14> either reject unauthorised reques ts or mark
them for manual authorisation according to CA policy. them for manual authorisation according to CA policy.
</t> </t>
</section> </section>
<section anchor="overview-cert-enrol" title="Certificate Enrolment/Renewal <section anchor="overview-cert-enrol" numbered="true" toc="default">
"> <name>Certificate Enrolment/Renewal</name>
<t>
A client starts an enrolment transaction (<xref target="PKCSReq" format="default
"/>) by creating a
certificate request using PKCS #10 and sends the request to the CA enveloped
using CMS (<xref target="message-obj" format="default"/>).
</t>
<t> <t>
A client starts an enrolment transaction (<xref target="PKCSReq"/>) by If the CA supports certificate renewal and the CA policy permits, then a new
creating a certificate request using PKCS #10 and sends it to the CA enveloped certificate with new validity dates can be issued, even though the old one is
using CMS (<xref target="message-obj"/>).
</t>
<t>
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. To renew an existing certificate, the client uses the RenewalReq still valid. To renew an existing certificate, the client uses the RenewalReq
message (see <xref target="pkiMessage-types"/>) and signs it with the existing message (see <xref target="pkiMessage-types" format="default"/>) and signs it wi
client certificate. The client SHOULD use a new keypair when requesting a new th the existing
certificate, but MAY request a new certificate using the old keypair. client certificate. The client <bcp14>SHOULD</bcp14> use a new keypair when req
uesting a new
certificate but <bcp14>MAY</bcp14> request a new certificate using the old keypa
ir.
</t> </t>
<t> <t>
If the CA returns a CertRep message (<xref target="CertRep"/>) with status set If the CA returns a CertRep message (<xref target="CertRep" format="default"/>) with status set
to PENDING, the client enters into polling mode by periodically sending a to PENDING, the client enters into polling mode by periodically sending a
CertPoll message (<xref target="CertPoll"/>) to the CA until the CA operator CertPoll message (<xref target="CertPoll" format="default"/>) to the CA until th
completes the manual authentication (approving or denying the request). The e CA operator
frequency of the polling operation is a CA/client configuration issue, and may completes the manual authentication (approving or denying the request). The
frequency of the polling operation is a CA/client configuration issue and may
range from seconds or minutes when the issue process is automatic but not range from seconds or minutes when the issue process is automatic but not
instantaneous, through to hours or days if the certificate issue operation instantaneous, through to hours or days if the certificate-issue operation
requires manual approval. requires manual approval.
</t> </t>
<t> <t>
If polling mode is being used then the client will send a single If polling mode is being used, then the client will send a single
PKCSReq/RenewalReq message (<xref target="PKCSReq"/>), followed by 0 or more PKCSReq/RenewalReq message (<xref target="PKCSReq" format="default"/>), followed
CertPoll messages (<xref target="CertPoll"/>). The CA will in return send 0 by 0 or more
or more CertRep messages (<xref target="CertRep"/>) with status set to PENDING CertPoll messages (<xref target="CertPoll" format="default"/>). The CA will, in
return, send 0
or more CertRep messages (<xref target="CertRep" format="default"/>) with status
set to PENDING
in response to CertPolls, followed by a single CertRep message (<xref in response to CertPolls, followed by a single CertRep message (<xref
target="CertRep"/>) with status set to either SUCCESS or FAILURE. target="CertRep" format="default"/>) with status set to either SUCCESS or
FAILURE.
</t> </t>
<section anchor="overview-client-state" title="Client State Trans <section anchor="overview-client-state" numbered="true" toc="default">
itions"> <name>Client State Transitions</name>
<t> <t>
The client state transitions during the SCEP process are indicated in <xref
target="state-diagram"/>.
</t> The client state transitions during the SCEP process are indicated in <xref targ
<figure anchor="state-diagram" title="State Transition Diagram" et="state-diagram" format="default"/>.
>
<artwork><![CDATA[
</t>
<figure anchor="state-diagram">
<name>State Transition Diagram</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
CertPoll CertPoll
+-----<----+ +-----<----+
| | | |
| | CertRep(PENDING) | | CertRep(PENDING)
| | | |
[CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> [CERT-ISSUED] [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] --------> [CERT-ISSUED]
^ PKCSReq | CertRep(SUCCESS) ^ PKCSReq | CertRep(SUCCESS)
| RenewalReq | | RenewalReq |
| | | |
+-----------------------+ +-----------------------+
CertRep(FAILURE) or CertRep(FAILURE) or
Max-time/max-polls exceeded Max-time/max-polls exceeded
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The certificate issue process starts at state CERT-NONEXISTENT. Sending a The certificate-issue process starts at state CERT-NONEXISTENT. Sending a
PKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING. PKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING.
</t> </t>
<t> <t>
If the CA returns a CertRep message with pkiStatus set to SUCCESS then the If the CA returns a CertRep message with pkiStatus set to SUCCESS, then the
state changes to CERT-ISSUED. state changes to CERT-ISSUED.
</t> </t>
<t> <t>
If the CA returns a CertRep message with pkiStatus set to FAILURE or there is 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. no response, then the state reverts back to CERT-NONEXISTENT.
</t> </t>
<t> <t>
If the CA returns a CertRep message with pkiStatus set to PENDING then the 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 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 message with status set to SUCCESS or FAILURE is received, a timeout occurs,
or the maximum number of polls has been exceeded. or the maximum number of polls has been exceeded.
</t> </t>
<figure> <t><xref target="automatic" /> shows a successful transaction in
<preamble>A successful transaction in automatic mode:</pr automatic mode</t>
eamble> <figure anchor="automatic">
<artwork><![CDATA[ <name>Automatic Mode</name>
<artwork type="" align="left" alt=""><![CDATA[
CLIENT CA SERVER CLIENT CA SERVER
PKCSReq: PKI cert. enrolment message PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = SUCCESS --------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached Certificate attached
<------------------------------ <------------------------------
Receive issued certificate. Receive issued certificate.
]]></artwork> ]]></artwork>
</figure> </figure>
<figure>
<preamble>A successful transaction in manual mode:</pream
ble>
<artwork><![CDATA[
<t><xref target="manual"/> shows a successful transaction in manual
mode:</t>
<figure anchor="manual">
<name>Manual Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
CLIENT CA SERVER CLIENT CA SERVER
PKCSReq: PKI cert. enrolment message PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = PENDING --------------------------------> CertRep: pkiStatus = PENDING
<------------------------------ <------------------------------
CertPoll: Polling message CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = PENDING --------------------------------> CertRep: pkiStatus = PENDING
<------------------------------ <------------------------------
................ <Manual identity authentication> ............... ................ <Manual identity authentication> ...............
skipping to change at line 493 skipping to change at line 436
CertPoll: Polling message CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = PENDING --------------------------------> CertRep: pkiStatus = PENDING
<------------------------------ <------------------------------
................ <Manual identity authentication> ............... ................ <Manual identity authentication> ...............
CertPoll: Polling message CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = SUCCESS --------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached Certificate attached
<------------------------------ <------------------------------
Receive issued certificate. Receive issued certificate.
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="overview-cert-access" title="Certificate Access"> <section anchor="overview-cert-access" numbered="true" toc="default">
<name>Certificate Access</name>
<t> <t>
A certificate query message is defined for clients to retrieve a copy of their 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 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 certificates locally to obtain a copy when needed. This functionality is not
intended to provide a general purpose certificate access service, which may be intended to provide a general-purpose certificate-access service, which may be
instead be achieved via <xref target="HTTP-certstore">HTTP certificate-store achieved instead via <xref target="RFC4387" format="default">HTTP certificate-st
access</xref> or LDAP. ore
access</xref> or Lightweight Directory Access Protocol (LDAP).
</t> </t>
<t> <t>
To retrieve a certificate from the CA, a client sends a request consisting of To retrieve 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 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 has saved the issuer name and the serial number of the issued certificate from
the previous enrolment transaction. The transaction to retrieve a certificate the previous enrolment transaction. The transaction to retrieve a certificate
consists of one GetCert (<xref target="GetCertCRL"/>) message and one CertRep consists of one GetCert (<xref target="GetCertCRL" format="default"/>) message a
(<xref target="CertRep"/>) message, as shown below. nd one CertRep
(<xref target="CertRep" format="default"/>) message, as shown in <xref target="r
etrieve"/>.
</t> </t>
<figure> <figure anchor="retrieve">
<artwork><![CDATA[ <name>Retrieving a Certificate</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
CLIENT CA SERVER CLIENT CA SERVER
GetCert: PKI certificate query message GetCert: PKI certificate query message
-------------------------------> CertRep: pkiStatus = SUCCESS -------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached Certificate attached
<----------------------------- <-----------------------------
Receive the certificate. Receive the certificate.
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="overview-CRL-access" title="CRL Access"> <section anchor="overview-CRL-access" numbered="true" toc="default">
<name>CRL Access</name>
<t> <t>
SCEP clients MAY request a CRL via one of three methods: SCEP clients <bcp14>MAY</bcp14> request a CRL via one of three methods:
</t> </t>
<t> <ol type="1">
<li>If the CA supports the <xref target="RFC5280" format="default">CRL
<list style="numbers"> Distribution
<t>If the CA supports the <xref target="PKIX">CRL Distribution
Points (CRLDPs) extension</xref> in issued certificates, then t he Points (CRLDPs) extension</xref> in issued certificates, then t he
CRL MAY be retrieved via the mechanism specified in the CRDLP.< CRL <bcp14>MAY</bcp14> be retrieved via the mechanism specified
/t> in the CRLDP.</li>
<li>If the CA supports <xref target="RFC4387" format="default">HTTP
<t>If the CA supports <xref target="HTTP-certstore">HTTP certificate-store access</xref>, then the CRL <bcp14>MAY</bcp14
certificate-store access</xref>, then the CRL MAY be retrieved > be retrieved via
via the <xref target="RFC5280" format="default">AuthorityInfoAcces<
the <xref target="PKIX">AuthorityInfoAcces</xref> location spec /xref> location specified
ified in the certificate.</li>
in the certificate.</t> <li>Only if the CA does not support CRLDPs or HTTP access should a
<t>Only if the CA does not support CRDLPs or HTTP access should
a
CRL query be composed by creating a GetCRL message consisting o f the CRL query be composed by creating a GetCRL message consisting o f the
issuer name and serial number from the certificate whose revoca tion issuer name and serial number from the certificate whose revoca tion
status is being queried.</t> status is being queried.</li>
</ol>
</list> <t>
</t>
<t>
The message is sent to the SCEP CA in the same way as the other SCEP requests. 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 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 CertRep PKI message, which contains only the CRL (no certificates) in a
degenerate certificates-only CMS Signed-Data message degenerate certificates-only CMS SignedData message
(<xref target="certs-only"/>), as shown below. (<xref target="certs-only" format="default"/>), as shown in <xref target="retrie
ve-CRL"/>.
</t>
<figure>
<artwork><![CDATA[
</t>
<figure anchor="retrieve-CRL">
<name>Retrieving a CRL</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
CLIENT CA SERVER CLIENT CA SERVER
GetCRL: PKI CRL query message GetCRL: PKI CRL query message
----------------------------------> ---------------------------------->
CertRep: CRL attached CertRep: CRL attached
<----------------------------- <-----------------------------
Receive the CRL Receive the CRL
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="overview-cert-rev" title="Certificate Revocation"> <section anchor="overview-cert-rev" numbered="true" toc="default">
<name>Certificate Revocation</name>
<t> <t>
SCEP does not specify a method to request certificate revocation. In order to 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 revoke a certificate, the client must contact the CA using a non-SCEP-defined me
mechanism. chanism.
</t>
</t> </section>
</section> <section anchor="MTI" numbered="true" toc="default">
<section anchor="MTI" title="Mandatory-to-Implement Functionality"> <name>Mandatory-to-Implement Functionality</name>
<t> <t>
At a minimum, all SCEP implementations compliant with this specification MUST At a minimum, all SCEP implementations compliant with this specification <bcp14>
support <xref target="CA-caps-HTTP">GetCACaps</xref>, MUST</bcp14>
<xref target="GetCACert">GetCACert</xref>, support <xref target="CA-caps-HTTP" format="default">GetCACaps</xref>,
<xref target="PKCSReq">PKCSReq</xref> (and its associated response messages), <xref target="GetCACert" format="default">GetCACert</xref>,
communication of binary data via <xref target="HTTP-GET-POST">HTTP <xref target="PKCSReq" format="default">PKCSReq</xref> (and its associated respo
POST</xref>, and the <xref target="AES">AES128-CBC</xref> and nse messages),
<xref target="SHA2">SHA-256</xref> algorithms to secure communication of binary data via <xref target="HTTP-GET-POST" format="default">H
<xref target="pkiMessage">pkiMessages</xref>. TTP
POST</xref>, and the <xref target="AES" format="default">AES128-CBC</xref> and
<xref target="SHA2" format="default">SHA-256</xref> algorithms to secure
<xref target="pkiMessage" format="default">pkiMessages</xref>.
</t> </t>
<t> <t>
For historical reasons implementations MAY support communications of binary For historical reasons, implementations <bcp14>MAY</bcp14> support communication
data via <xref target="HTTP-GET-POST">HTTP GET</xref>, and the triple DES-CBC s of binary
and SHA-1 algorithms to secure <xref target="pkiMessage">pkiMessages</xref>. data via <xref target="HTTP-GET-POST" format="default">HTTP GET</xref>, and the
Implementations MUST NOT support the obsolete and/or insecure single DES and triple DES-CBC
and SHA-1 algorithms to secure <xref target="pkiMessage" format="default">pkiMes
sages</xref>.
Implementations <bcp14>MUST NOT</bcp14> support the obsolete and/or insecure sin
gle DES and
MD5 algorithms used in earlier versions of this specification, since the MD5 algorithms used in earlier versions of this specification, since the
unsecured nature of GetCACaps means that an in-path attacker can trivially unsecured nature of GetCACaps means that an in-path attacker can trivially
roll back the encryption used to these insecure algorithms, see <xref roll back the encryption used to these insecure algorithms; see <xref
target="security-getcacaps"/>. target="security-getcacaps" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<!-- ======================================================================
--> <section anchor="message-obj" numbered="true" toc="default">
<section anchor="message-obj" title="SCEP Secure Message Objects"> <name>SCEP Secure Message Objects</name>
<t> <t>
CMS is a general enveloping mechanism that enables both signed and encrypted CMS is a general enveloping mechanism that enables both signed and encrypted
transmission of arbitrary data. SCEP messages that require confidentiality transmission of arbitrary data. SCEP messages that require confidentiality
use two layers of CMS, as shown using ASN.1-like pseudocode in use two layers of CMS, as shown using ASN.1-like pseudocode in
<xref target="cms-layering"/>. By applying both enveloping and signing <xref target="cms-layering" format="default"/>. By applying both enveloping and signing
transformations, the SCEP message is protected both for the integrity of its transformations, the SCEP message is protected both for the integrity of its
end-to-end transaction information and the confidentiality of its information end-to-end transaction information and the confidentiality of its information
portion. portion.
</t> </t>
<figure anchor="cms-layering" title="CMS Layering"> <figure anchor="cms-layering">
<artwork><![CDATA[ <name>CMS Layering</name>
<sourcecode type="pseudocode">
pkiMessage { pkiMessage {
contentType = signedData { pkcs-7 2 }, contentType = signedData { pkcs-7 2 },
content { content {
digestAlgorithms, digestAlgorithms,
encapsulatedContentInfo { encapsulatedContentInfo {
eContentType = data { pkcs-7 1 }, eContentType = data { pkcs-7 1 },
eContent { -- pkcsPKIEnvelope, optional eContent { -- pkcsPKIEnvelope, optional
contentType = envelopedData { pkcs-7 3 }, contentType = envelopedData { pkcs-7 3 },
content { content {
recipientInfo, recipientInfo,
skipping to change at line 669 skipping to change at line 604
transactionID, transactionID,
messageType, messageType,
pkiStatus, pkiStatus,
failInfo, -- Optional failInfo, -- Optional
senderNonce / recipientNonce, senderNonce / recipientNonce,
}, },
signature signature
} }
} }
} }
</sourcecode>
]]></artwork> </figure>
</figure>
<t> <t>
When a particular SCEP message carries data, this data is carried in the When a particular SCEP message carries data, this data is carried in the
messageData. CertRep messages will lack any signed content and consist only messageData. CertRep messages will lack any signed content and consist only
of a pkcsPKIEnvelope (<xref target="pkcsPKIEnvelope"/>). of a pkcsPKIEnvelope (<xref target="pkcsPKIEnvelope" format="default"/>).
</t> </t>
<t> <t>
The remainder of this document will refer only to 'messageData', but it is The remainder of this document will refer only to "messageData", but it is
understood to always be encapsulated in the pkcsPKIEnvelope (<xref understood to always be encapsulated in the pkcsPKIEnvelope (<xref target="pkcsP
target="pkcsPKIEnvelope"/>). The format of the data in the messageData is KIEnvelope" format="default"/>). The format of the data in the messageData is
defined by the messageType attribute (see <xref target="pkiMessage"/>) of the defined by the messageType attribute (see <xref target="pkiMessage" format="defa
Signed-Data. If there is no messageData to be transmitted, the entire ult"/>) of the
pkcsPKIEnvelope MUST be omitted. SignedData. If there is no messageData to be transmitted, the entire
pkcsPKIEnvelope <bcp14>MUST</bcp14> be omitted.
</t> </t>
<t> <t>
Samples of SCEP messages are available through the Samples of SCEP messages are available through the
<xref target="JSCEP">JSCEP project</xref> in the src/samples directory. <xref target="JSCEP" format="default">JSCEP project</xref> in the src/samples di rectory.
</t> </t>
<section anchor="message-processing" title="SCEP Message Object Process <section anchor="message-processing" numbered="true" toc="default">
ing"> <name>SCEP Message Object Processing</name>
<t> <t>
Creating a SCEP message consists of several stages. The content to be Creating a SCEP message consists of several stages. The content to be
conveyed (in other words the messageData) is first encrypted, and the conveyed (in other words, the messageData) is first encrypted, and the
encrypted content is then signed. encrypted content is then signed.
</t> </t>
<t> <t>
The form of encryption to be applied depends on the capabilities of the 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) 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 then the messageData is encrypted using the recipient's public key with the
CMS KeyTransRecipientInfo mechanism. If the key is not encryption-capable CMS KeyTransRecipientInfo mechanism. If the key is not encryption capable
(for example DSA or ECDSA) then the messageData is encrypted using the (for example, DSA or ECDSA), then
the messageData is encrypted using the
challengePassword with the CMS PasswordRecipientInfo mechanism. challengePassword with the CMS PasswordRecipientInfo mechanism.
</t> </t>
<t> <t>
Once the messageData has been encrypted, it is signed with the sender's public 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. key. This completes the SCEP message, which is then sent to the recipient.
</t> </t>
<t> <t>
Note that some early implementations of this specification dealt with Note that some early implementations of this specification dealt with keys
non-encryption-capable keys by omitting the encryption stage, based on the that were not encryption capable by omitting the encryption stage, based on the
text in <xref target="message-obj"/> that indicated that "the EnvelopedData is text in <xref target="message-obj" format="default"/> that indicated that "the E
omitted". This alternative processing mechanism SHOULD NOT be used since it nvelopedData is
omitted". This alternative processing mechanism <bcp14>SHOULD NOT</bcp14> be us
ed since it
exposes in cleartext the challengePassword used to authorise the certificate exposes in cleartext the challengePassword used to authorise the certificate
issue. issue.
</t> </t>
<t> <t>
</t> </t>
</section> </section>
<section anchor="pkiMessage" title="SCEP pkiMessage"> <section anchor="pkiMessage" numbered="true" toc="default">
<t> <name>SCEP pkiMessage</name>
<t>
The basic building block of all secured SCEP messages is the SCEP pkiMessage. 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 It consists of a CMS SignedData content type. The following restrictions
apply: apply:
</t> </t>
<t> <ul spacing="compact">
<li>The eContentType in encapsulatedContentInfo <bcp14>MUST</bcp14> be
<list style="symbols"> data ({pkcs-7
1}).</li>
<t>The eContentType in encapsulatedContentInfo MUST be data ({p <li>The signed content, if present (FAILURE and PENDING CertRep
kcs-7 messages will lack any signed content),
1}).</t> <bcp14>MUST</bcp14> be a pkcsPKIEnvelope
(<xref target="pkcsPKIEnvelope" format="default"/>)
<t>The signed content, if present (FAILURE and PENDING CertRep and <bcp14>MUST</bcp14> match the
messages will lack any signed content), MUST be a pkcsPK messageType attribute.</li>
IEnvelope <li>The SignerInfo <bcp14>MUST</bcp14> contain a set of authenticatedA
(<xref target="pkcsPKIEnvelope"/>), and MUST match the ttributes
messageType attribute.</t> (<xref target="signed-attrs" format="default"/>).</li>
</ul>
<t>The SignerInfo MUST contain a set of authenticatedAttributes <section anchor="signed-attrs" numbered="true" toc="default">
(<xref target="signed-attrs"/>).</t> <name>Signed Transaction Attributes</name>
<t>
</list>
</t>
<section anchor="signed-attrs" title="Signed Transaction Attribut
es">
<t>
At a minimum, all messages MUST contain the following authenticatedAttributes:
</t>
<t>
<list style="symbols">
<t>A transactionID attribute (see <xref
target="transactionID"/>).</t>
<t>A messageType attribute (see <xref target="messageType
"/>).</t>
<t>A fresh senderNonce attribute (see <xref
target="nonces"/>). Note however the comment about
senderNonces and polling in <xref target="CertRep"/> <
/t>
<t>Any attributes required by CMS.</t>
</list> At a minimum, all messages <bcp14>MUST</bcp14> contain the following authenticat edAttributes:
</t> </t>
<t> <ul spacing="compact">
<li>A transactionID attribute (see <xref target="transactionID" form
at="default"/>).</li>
<li>A messageType attribute (see <xref target="messageType" format="
default"/>).</li>
<li>A fresh senderNonce attribute (see <xref target="nonces"
format="default"/>). However, note the comment about
senderNonces and polling in <xref target="CertRep" format="default"/>
</li>
<li>Any attributes required by CMS.</li>
</ul>
<t>
If the message is a CertRep, it MUST also include the following If the message is a CertRep, it <bcp14>MUST</bcp14> also include the following
authenticatedAttributes: authenticatedAttributes:
</t> </t>
<t> <ul spacing="compact">
<li>A pkiStatus attribute (see <xref target="pkiStatus" format="defa
<list style="symbols"> ult"/>).</li>
<li>failInfo and optional failInfoText attributes (see <xref
<t>A pkiStatus attribute (see <xref target="pkiStatus"/>) target="failInfo" format="default"/>) if pkiStatus = FAILURE.</li>
.</t> <li>A recipientNonce attribute (see <xref target="nonces" format="de
fault"/>) copied
<t>A failInfo and optional failInfotext attribute (see <x from the senderNonce in the request that this is a response
ref to.</li>
target="failInfo"/>) if pkiStatus = FAILURE.</t> </ul>
<t>
<t>A recipientNonce attribute (see <xref target="nonces"/
>) copied
from the senderNonce in the request that this is a res
ponse
to.</t>
</list>
</t>
<t>
The following transaction attributes are encoded as authenticated attributes,
and are carried in the SignerInfo for this Signed-Data.
</t>
<texttable align="left">
<ttcol>Attribute</ttcol>
<ttcol>Encoding</ttcol>
<ttcol>Comment</ttcol>
<c>transactionID</c><c>PrintableString</c><c>Unique ID fo
r this
transaction as a text string</c>
<c>messageType</c><c>PrintableString</c><c>Decimal value
as a
numeric text string</c>
<c>pkiStatus</c><c>PrintableString</c><c>Decimal value as
a
numeric text string</c>
<c>failInfo</c><c>PrintableString</c><c>Decimal value as
a
numeric text string</c>
<c>failInfoText</c><c>UTF8String</c><c>Descriptive text f
or the
failInfo value</c>
<c>senderNonce</c><c>OCTET STRING</c><c>Random nonce as a
16-byte
binary data string</c>
<c>recipientNonce</c><c>OCTET STRING</c><c>Random nonce a
s a
16-byte binary data string</c>
</texttable>
<texttable align="left">
<preamble>The OIDs used for these attributes are as
follows:</preamble>
<ttcol>Name</ttcol>
<ttcol>ASN.1 Definition</ttcol>
<c>id-VeriSign</c><c>OBJECT_IDENTIFIER ::= {2 16 US(840)
1
VeriSign(113733)}</c>
<c>id-pki</c><c>OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)
}</c>
<c>id-attributes</c><c>OBJECT_IDENTIFIER ::= {id-pki
attributes(9)}</c>
<c>id-transactionID</c><c>OBJECT_IDENTIFIER ::= {id-attri
butes
transactionID(7)}</c>
<c>id-messageType</c><c>OBJECT_IDENTIFIER ::= {id-attribu
tes
messageType(2)}</c>
<c>id-pkiStatus</c><c>OBJECT_IDENTIFIER ::= {id-attribute
s
pkiStatus(3)}</c>
<c>id-failInfo</c><c>OBJECT_IDENTIFIER ::= {id-attributes
failInfo(4)}</c>
<c>id-senderNonce</c><c>OBJECT_IDENTIFIER ::= {id-attribu
tes
senderNonce(5)}</c>
<c>id-recipientNonce</c><c>OBJECT_IDENTIFIER ::= {id-attr
ibutes
recipientNonce(6)}</c>
<c>id-scep</c><c>OBJECT IDENTIFIER ::= {id-pkix TBD1}</c> The following transaction attributes are encoded as authenticated attributes
and carried in the SignerInfo for this SignedData.
<c>id-scep-failInfoText</c><c>OBJECT IDENTIFIER ::= {id-s </t>
cep 1}</c> <table align="left">
<name>SCEP Attributes</name>
<thead>
<tr>
<th align="left">Attribute</th>
<th align="left">Encoding</th>
<th align="left">Comment</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">transactionID</td>
<td align="left">PrintableString</td>
<td align="left">Unique ID for this
transaction as a text string</td>
</tr>
<tr>
<td align="left">messageType</td>
<td align="left">PrintableString</td>
<td align="left">Decimal value as a
numeric text string</td>
</tr>
<tr>
<td align="left">pkiStatus</td>
<td align="left">PrintableString</td>
<td align="left">Decimal value as a
numeric text string</td>
</tr>
<tr>
<td align="left">failInfo</td>
<td align="left">PrintableString</td>
<td align="left">Decimal value as a
numeric text string</td>
</tr>
<tr>
<td align="left">failInfoText</td>
<td align="left">UTF8String</td>
<td align="left">Descriptive text for the
failInfo value</td>
</tr>
<tr>
<td align="left">senderNonce</td>
<td align="left">OCTET STRING</td>
<td align="left">Random nonce as a 16-byte
binary data string</td>
</tr>
<tr>
<td align="left">recipientNonce</td>
<td align="left">OCTET STRING</td>
<td align="left">Random nonce as a
16-byte binary data string</td>
</tr>
</tbody>
</table>
<t>The OIDs used for these attributes are as
follows:</t>
</texttable> <table align="left">
<t> <name>SCEP Attribute OIDs</name>
<thead>
<tr>
<th align="left">Name</th>
<th align="left">ASN.1 Definition</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">id-VeriSign</td>
<td align="left">OBJECT_IDENTIFIER ::= {2 16 US(840) 1
VeriSign(113733)}</td>
</tr>
<tr>
<td align="left">id-pki</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)}</td>
</tr>
<tr>
<td align="left">id-attributes</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-pki
attributes(9)}</td>
</tr>
<tr>
<td align="left">id-transactionID</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
transactionID(7)}</td>
</tr>
<tr>
<td align="left">id-messageType</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
messageType(2)}</td>
</tr>
<tr>
<td align="left">id-pkiStatus</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
pkiStatus(3)}</td>
</tr>
<tr>
<td align="left">id-failInfo</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
failInfo(4)}</td>
</tr>
<tr>
<td align="left">id-senderNonce</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
senderNonce(5)}</td>
</tr>
<tr>
<td align="left">id-recipientNonce</td>
<td align="left">OBJECT_IDENTIFIER ::= {id-attributes
recipientNonce(6)}</td>
</tr>
<tr>
<td align="left">id-scep</td>
<td align="left">OBJECT IDENTIFIER ::= {id-pkix 24}</td>
</tr>
<tr>
<td align="left">id-scep-failInfoText</td>
<td align="left">OBJECT IDENTIFIER ::= {id-scep 1}</td>
</tr>
</tbody>
</table>
<t>
The attributes are detailed in the following sections. The attributes are detailed in the following sections.
</t> </t>
<section anchor="transactionID" title="transactionID"> <section anchor="transactionID" numbered="true" toc="default">
<t> <name>transactionID</name>
<t>
A PKI operation is a transaction consisting of the messages exchanged between 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 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 client when starting a transaction. The client <bcp14>MUST</bcp14> use a unique
the transaction identifier, encoded as a PrintableString, which MUST be used string as
for all PKI messages exchanged for a given operation such as a certificate the transaction identifier, encoded as a PrintableString, which <bcp14>MUST</bcp
14> be used
for all PKI messages exchanged for a given operation, such as a certificate
issue. issue.
</t> </t>
<t> <t>
Note that the transactionID must be unique, but not necessarily randomly Note that the transactionID must be unique, but not necessarily randomly
generated. For example it may be a value assigned by the CA to allow the generated. For example, it may be a value assigned by the CA to allow the
client to be identified by their transactionID, using a value such as the client to be identified by their transactionID, using a value such as the
client device's EUI or RTU ID or a similar unique identifier. This can be client device's Extended Unique Identifier (EUI), Remote Terminal Unit (RTU) ID,
useful when the client doesn't have a pre-assigned Distinguished Name that the or a similar unique
CA can identify their request through, for example when enrolling SCADA identifier. This can be
devices. useful when the client doesn't have a preassigned Distinguished Name through
which the CA can identify their request -- for example, when enrolling
</t> Supervisory Control and Data Acquisition (SCADA) devices.
</section>
<section anchor="messageType" title="messageType">
<t>
</t>
</section>
<section anchor="messageType" numbered="true" toc="default">
<name>messageType</name>
<t>
The messageType attribute specifies the type of operation performed by the The messageType attribute specifies the type of operation performed by the
transaction. This attribute MUST be included in all PKI messages. The transaction. This attribute <bcp14>MUST</bcp14> be included in all PKI messages . The
following message types are defined: following message types are defined:
</t>
</t> <table anchor="scep-message-types">
<t> <name>SCEP Message Types</name>
<thead>
<list style="symbols"> <tr>
<th>Value</th>
<t>CertRep ("3") -- Response to certificate or CRL requ <th>Name</th>
est.</t> <th>Description</th>
</tr>
<t>RenewalReq ("17") -- PKCS #10 certificate request </thead>
authenticated with an existing certificate.</t> <tbody>
<t>PKCSReq ("19") -- PKCS #10 certificate request authe
nticated
with a shared secret.</t>
<t>CertPoll ("20") -- Certificate polling in manual enr
olment.</t>
<t>GetCert ("21") -- Retrieve a certificate.</t>
<t>GetCRL ("22") -- Retrieve a CRL.</t>
</list>
</t> <tr>
<t> <td>0</td>
<td>Reserved</td>
<td></td>
</tr>
<tr>
<td>3</td>
<td>CertRep</td>
<td>Response to certificate or CRL request.</td>
</tr>
<tr>
<td>17</td>
<td>RenewalReq</td>
<td>PKCS #10 certificate request authenticated with an existing certificat
e.</td>
</tr>
<tr>
<td>19</td>
<td>PKCSReq</td>
<td>PKCS #10 certificate request authenticated with a shared secret.</td>
</tr>
<tr>
<td>20</td>
<td>CertPoll</td>
<td>Certificate polling in manual enrolment.</td>
</tr>
<tr>
<td>21</td>
<td>GetCert</td>
<td>Retrieve a certificate.</td>
</tr>
<tr>
<td>22</td>
<td>GetCRL</td>
<td>Retrieve a CRL.</td>
</tr>
</tbody>
</table>
Message types not defined above MUST be treated as an error unless their use <t>
has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. Message types not defined above <bcp14>MUST</bcp14> be treated as errors unless
their use
has been negotiated through <xref target="CA-caps-HTTP" format="default">GetCACa
ps</xref>.
</t> </t>
</section> </section>
<section anchor="pkiStatus" title="pkiStatus"> <section anchor="pkiStatus" numbered="true" toc="default">
<t> <name>pkiStatus</name>
<t>
All response messages MUST include transaction status information, which is All response messages <bcp14>MUST</bcp14> include transaction status information , which is
defined as a pkiStatus attribute: defined as a pkiStatus attribute:
</t>
</t> <table anchor="tab-pkiStatus">
<t> <name>pkiStatus Attributes</name>
<thead>
<list style="symbols"> <tr>
<th>Value</th>
<t>SUCCESS ("0") -- Request granted.</t> <th>Name</th>
<th>Description</th>
<t>FAILURE ("2") -- Request rejected. In this case the </tr>
failInfo </thead>
attribute, as defined in <xref target="failInfo" <tbody>
/>, MUST also <tr>
be present.</t> <td>0</td>
<td>SUCCESS</td>
<t>PENDING ("3") -- Request pending for manual approval <td>Request granted.</td>
.</t> </tr>
<tr>
</list> <td>2</td>
<td>FAILURE</td>
</t> <td>Request rejected. In this case, the failInfo attribute, as defined
<t> in <xref target="failInfo" format="default"/>, <bcp14>MUST</bcp14> also
be present.</td>
PKI status values not defined above MUST be treated as an error unless their </tr>
use has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. <tr>
<td>3</td>
</t> <td>PENDING</td>
</section> <td>Request pending for manual approval.</td>
<section anchor="failInfo" title="failInfo and failInfoText"> </tr>
<t> </tbody>
</table>
The failInfo attribute MUST contain one of the following failure reasons:
</t>
<t>
<list style="symbols">
<t>badAlg ("0") -- Unrecognized or unsupported algorith
m.</t>
<t>badMessageCheck ("1") -- Integrity check (meaning si
gnature
verification of the CMS message) failed.</t>
<t>badRequest ("2") -- Transaction not permitted or
supported.</t>
<t>badTime ("3") -- The signingTime attribute from the
CMS
authenticatedAttributes was not sufficiently clo
se to the
system time. This condition may occur if the CA
is concerned
about replays of old messages.</t>
<t>badCertId ("4") -- No certificate could be identifie
d
matching the provided criteria.</t>
</list>
</t>
<t>
Failure reasons not defined above MUST be treated as an error unless their use <t>
has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. PKI status values not defined above <bcp14>MUST</bcp14> be treated as errors unl
ess their
use has been negotiated through <xref target="CA-caps-HTTP" format="default">Get
CACaps</xref>.
</t>
</section>
<section anchor="failInfo" numbered="true" toc="default">
<name>failInfo and failInfoText</name>
<t>
The failInfo attribute <bcp14>MUST</bcp14> contain one of the following failure
reasons:
</t>
</t> <table anchor="tab-failInfo">
<t> <name>failInfo Attributes</name>
<thead>
<tr>
<th>Value</th>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>badAlg</td>
<td>Unrecognised or unsupported algorithm.</td>
</tr>
<tr>
<td>1</td>
<td>badMessageCheck</td>
<td>Integrity check (meaning signature verification of the CMS message) fa
iled.</td>
</tr>
<tr>
<td>2</td>
<td>badRequest</td>
<td>Transaction not permitted or supported.</td>
</tr>
<tr>
<td>3</td>
<td>badTime</td>
<td>The signingTime attribute from the CMS authenticatedAttributes was
not sufficiently close to the system time. This condition may occur if
the CA is concerned about replays of old messages.</td>
</tr>
<tr>
<td>4</td>
<td>badCertId</td>
<td>No certificate could be identified matching the provided criteria.</td
>
</tr>
</tbody>
</table>
<t>
Failure reasons not defined above <bcp14>MUST</bcp14> be treated as errors unles
s their use
has been negotiated through <xref target="CA-caps-HTTP" format="default">GetCACa
ps</xref>.
</t>
<t>
The failInfoText is a free-form UTF-8 text string that provides further 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 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 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 what's provided by the near-universal failInfo = badRequest status. Since
this is a free-form text string intended for interpretation by humans, this is a free-form text string intended for interpretation by humans,
implementations SHOULD NOT assume that it has any type of machine-processable implementations <bcp14>SHOULD NOT</bcp14> assume that it has any type of machine -processable
content. content.
</t>
</t> </section>
</section> <section anchor="nonces" numbered="true" toc="default">
<section anchor="nonces" title="senderNonce and recipientNonce" <name>senderNonce and recipientNonce</name>
> <t>
<t> The senderNonce and recipientNonce attributes are each a 16-byte random number
The senderNonce and recipientNonce attributes are a 16 byte random number
generated for each transaction. These are intended to prevent replay attacks. generated for each transaction. These are intended to prevent replay attacks.
</t>
</t> <t>
<t> When a sender sends a PKI message to a recipient, a fresh senderNonce <bcp14>MUS
T</bcp14> be
When a sender sends a PKI message to a recipient, a fresh senderNonce MUST be included in the message. The recipient <bcp14>MUST</bcp14> copy the senderNonce
included in the message. The recipient MUST copy the senderNonce into the into the
recipientNonce of the reply as a proof of liveliness. The original sender recipientNonce of the reply as a proof of liveliness. The original sender
MUST verify that the recipientNonce of the reply matches the senderNonce it <bcp14>MUST</bcp14> verify that the recipientNonce of the reply matches the send
sent in the request. If the nonce does not match then the message MUST be erNonce it
sent in the request. If the nonce does not match, then the message <bcp14>MUST<
/bcp14> be
rejected. rejected.
</t>
</t> <t>
<t>
Note that since SCEP exchanges consist of a single request followed by a 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 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 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 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. senderNonce in the client's request and recipientNonce in the CA's reply.
</t>
</t> </section>
</section> </section>
</section> <section anchor="pkcsPKIEnvelope" numbered="true" toc="default">
<section anchor="pkcsPKIEnvelope" title="SCEP pkcsPKIEnvelope"> <name>SCEP pkcsPKIEnvelope</name>
<t> <t>
The information portion of a SCEP message is carried inside an EnvelopedData The information portion of a SCEP message is carried inside an EnvelopedData
content type, as defined in CMS, with the following restrictions: content type, as defined in CMS, with the following restrictions:
</t> </t>
<t> <ul spacing="compact">
<li>contentType in encryptedContentInfo <bcp14>MUST</bcp14> be data
<list style="symbols"> ({pkcs-7
1}).</li>
<t>contentType in encryptedContentInfo MUST be data ({pkc
s-7
1}).</t>
<t>encryptedContent MUST be the SCEP message being transp
orted
(see <xref target="SCEP-trans"/>), and must match the
messageType authenticated Attribute in the pkiMessage.
</t>
</list>
</t> <li>encryptedContent <bcp14>MUST</bcp14> be the SCEP message being t
</section> ransported
</section> (see <xref target="SCEP-trans" format="default"/>)
<section anchor="pkiMessage-types" title="SCEP pkiMessage types"> and <bcp14>MUST</bcp14> match the
<t> messageType authenticated Attribute in the pkiMessage.
</li>
</ul>
</section>
</section>
<section anchor="pkiMessage-types" numbered="true" toc="default">
<name>SCEP pkiMessage types</name>
<t>
All of the messages in this section are pkiMessages (<xref All of the messages in this section are pkiMessages (<xref target="pkiMessage" f
target="pkiMessage"/>), where the type of the message MUST be specified in the ormat="default"/>), where the type of the message <bcp14>MUST</bcp14> be specifi
'messageType' authenticated Attribute. Each section defines a valid message ed in the
"messageType" authenticated Attribute. Each section defines a valid message
type, the corresponding messageData formats, and mandatory authenticated type, the corresponding messageData formats, and mandatory authenticated
attributes for that type. attributes for that type.
</t> </t>
<section anchor="PKCSReq" title="PKCSReq/RenewalReq"> <section anchor="PKCSReq" numbered="true" toc="default">
<t> <name>PKCSReq/RenewalReq</name>
<t>
The messageData for this type consists of a PKCS #10 Certificate Request. The The messageData for this type consists of a PKCS #10 Certificate Request. The
certificate request MUST contain at least the following items: certificate request <bcp14>MUST</bcp14> contain at least the following items:
</t>
<t>
<list style="symbols">
<t>The subject Distinguished Name.</t>
<t>The subject public key.</t>
<t>For a PKCSReq and if authorisation based on a shared s
ecret is
being used, a challengePassword attribute.</t>
</list>
</t> </t>
<t> <ul spacing="compact">
<li>The subject Distinguished Name.</li>
<li>The subject public key.</li>
<li>For a PKCSReq, if authorisation based on a shared secret is
being used, a challengePassword attribute.</li>
</ul>
<t>
In addition the message must contain the the authenticatedAttributes specified i In addition, the message must contain the authenticatedAttributes specified in
n <xref target="signed-attrs" format="default"/>.
<xref target="signed-attrs"/>.
</t> </t>
</section> </section>
<section anchor="CertRep" title="CertRep"> <section anchor="CertRep" numbered="true" toc="default">
<t> <name>CertRep</name>
<t>
The messageData for this type consists of a degenerate certificates-only CMS The messageData for this type consists of a degenerate certificates-only CMS
Signed-Data message (<xref target="certs-only"/>). The exact content required SignedData message (<xref target="certs-only" format="default"/>). The exact co ntent required
for the reply depends on the type of request that this message is a response for the reply depends on the type of request that this message is a response
to. The request types are detailed in <xref target="CertRep-success"/> and in to. The request types are detailed in Sections <xref target="CertRep-success"
<xref target="SCEP-trans"/>. In addition the message must contain the the format="counter"/> and <xref target="SCEP-trans" format="counter"/>. In
authenticatedAttributes specified in <xref target="signed-attrs"/>. addition, the message must contain the
authenticatedAttributes specified in <xref target="signed-attrs" format="default
</t> "/>.
<t>
Earlier versions of this specification required that this message include a </t>
<t>
Earlier draft versions of this specification required that this message include
a
senderNonce alongside the recipientNonce, which was to be used to chain to senderNonce alongside the recipientNonce, which was to be used to chain to
subsequent polling operations. However if a single message was lost during subsequent polling operations. However, if a single message was lost during
the potentially extended interval over which polling could take place (see the potentially extended interval over which polling could take place (see
<xref target="state-trans"/> for an example of this) then if the <xref target="state-trans" format="default"/> for an example of this), then if t
implementation were to enforce this requirement the overall transaction would he
fail even though nothing had actually gone wrong. Because of this issue, implementation were to enforce this requirement, the overall transaction would
implementations mostly ignored the requirement to carry this nonce over to fail, even though nothing had actually gone wrong. Because of this issue,
subsequent polling messages or to verify its presence. More recent versions implementations mostly ignored the requirement to either carry this nonce over t
o
subsequent polling messages or verify its presence. More recent versions
of the specification no longer require the chaining of nonces across polling of the specification no longer require the chaining of nonces across polling
operations. operations.
</t> </t>
<section anchor="CertRep-success" title="CertRep SUCCESS"> <section anchor="CertRep-success" numbered="true" toc="default">
<t> <name>CertRep SUCCESS</name>
<t>
When the pkiStatus attribute is set to SUCCESS, the messageData for this When the pkiStatus attribute is set to SUCCESS, the messageData for this
message consists of a degenerate certificates-only CMS Signed-Data message message consists of a degenerate certificates-only CMS SignedData message
(<xref target="certs-only"/>). The content of this degenerate (<xref target="certs-only" format="default"/>). The content of this degenerate
certificates-only Signed-Data depends on what the original request was, as certificates-only SignedData message depends on what the original request was, a
outlined below. s
outlined in <xref target="success"/>.
</t>
<texttable align="left">
<ttcol>Request-type</ttcol>
<ttcol>Reply-contents</ttcol>
<c>PKCSReq</c><c>The reply MUST contain at least the is
sued
certificate in the certificates field of the Sig
ned-Data.
The reply MAY contain additional certificates, b
ut the issued
certificate MUST be the leaf certificate.</c>
<c>RenewalReq</c><c>Same as PKCSReq</c>
<c>CertPoll</c><c>Same as PKCSReq</c>
<c>GetCert</c><c>The reply MUST contain at least the re
quested
certificate in the certificates field of the Sig
ned-Data.
The reply MAY contain additional certificates, b
ut the
requested certificate MUST be the leaf certifica
te.</c>
<c>GetCRL</c><c>The reply MUST contain the CRL in the c
rls field
of the Signed-Data.</c>
</texttable> </t>
</section> <table align="left" anchor="success">
<section anchor="CertRep-failure" title="CertRep FAILURE"> <name>CertRep Response Types</name>
<t> <thead>
<tr>
<th align="left">Request-type</th>
<th align="left">Reply-contents</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">PKCSReq</td>
<td align="left">The reply <bcp14>MUST</bcp14> contain at leas
t the issued
certificate in the certificates field of the SignedData.
The reply <bcp14>MAY</bcp14> contain additional certificates, b
ut the issued
certificate <bcp14>MUST</bcp14> be the leaf certificate.</td>
</tr>
<tr>
<td align="left">RenewalReq</td>
<td align="left">Same as PKCSReq</td>
</tr>
<tr>
<td align="left">CertPoll</td>
<td align="left">Same as PKCSReq</td>
</tr>
<tr>
<td align="left">GetCert</td>
<td align="left">The reply <bcp14>MUST</bcp14> contain at leas
t the requested
certificate in the certificates field of the Sig
nedData.
The reply <bcp14>MAY</bcp14> contain additional
certificates, but the
requested certificate <bcp14>MUST</bcp14> be the
leaf certificate.</td>
</tr>
<tr>
<td align="left">GetCRL</td>
<td align="left">The reply <bcp14>MUST</bcp14> contain the
CRL in the crls field of the SignedData.</td>
</tr>
</tbody>
</table>
</section>
<section anchor="CertRep-failure" numbered="true" toc="default">
<name>CertRep FAILURE</name>
<t>
When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a When the pkiStatus attribute is set to FAILURE, the reply <bcp14>MUST</bcp14> al
failInfo (<xref target="failInfo"/>) attribute set to the appropriate error so contain a
condition describing the failure. The reply MAY also contain a failInfoText failInfo (<xref target="failInfo" format="default"/>) attribute set to the appro
priate error
condition describing the failure. The reply <bcp14>MAY</bcp14> also contain a f
ailInfoText
attribute providing extended details on why the operation failed, typically to attribute providing extended details on why the operation failed, typically to
expand on the catch-all failInfo = badRequest status. The pkcsPKIEnvelope expand on the catchall failInfo = badRequest status. The pkcsPKIEnvelope
(<xref target="pkcsPKIEnvelope"/>) MUST be omitted. (<xref target="pkcsPKIEnvelope" format="default"/>) <bcp14>MUST</bcp14> be omitt
ed.
</t>
</section>
<section anchor="CertRep-pending" title="CertRep PENDING">
<t>
When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (<xref </t>
target="pkcsPKIEnvelope"/>) MUST be omitted. </section>
<section anchor="CertRep-pending" numbered="true" toc="default">
<name>CertRep PENDING</name>
<t>
</t> When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (<xref targe
</section> t="pkcsPKIEnvelope" format="default"/>) <bcp14>MUST</bcp14> be omitted.
</section>
<section anchor="CertPoll" title="CertPoll (GetCertInitial)">
<t>
This message is used for certificate polling. For unknown reasons it was </t>
referred to as "GetCertInitial" in earlier versions of this specification. </section>
</section>
<section anchor="CertPoll" numbered="true" toc="default">
<name>CertPoll (GetCertInitial)</name>
<t>
This message is used for certificate polling. For unknown reasons, it was
referred to as "GetCertInitial" in earlier draft versions of this specification.
The messageData for this type consists of an IssuerAndSubject: The messageData for this type consists of an IssuerAndSubject:
</t>
</t> <sourcecode>
<figure>
<artwork><![CDATA[
issuerAndSubject ::= SEQUENCE { issuerAndSubject ::= SEQUENCE {
issuer Name, issuer Name,
subject Name subject Name
} }
</sourcecode>
]]></artwork> <t>
</figure> The issuer is set to the subjectName of the CA (in other words, the intended
<t>
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 issuerName of the certificate that's being requested). The subject is set to
the subjectName used when requesting the certificate. the subjectName used when requesting the certificate.
</t>
</t> <t>
<t> 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
Note that both of these fields are redundant, the CA is identified by the that the message is being sent to), and the client/transaction being polled is
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 identified by the transactionID. Both of these fields can be processed by the
CA without going through the cryptographically expensive process of unwrapping CA without going through the cryptographically expensive process of unwrapping
and processing the issuerAndSubject. For this reason implementations SHOULD and processing the issuerAndSubject. For this reason, implementations <bcp14>SH OULD</bcp14>
assume that the polling operation will be controlled by the recipientInfo and assume that the polling operation will be controlled by the recipientInfo and
transactionID rather than the contents of the messageData. In addition the transactionID rather than the contents of the messageData. In addition, the
message must contain the the authenticatedAttributes specified in <xref message must contain the authenticatedAttributes specified in <xref
target="signed-attrs"/>. target="signed-attrs" format="default"/>.
</t> </t>
</section> </section>
<section anchor="GetCertCRL" title="GetCert and GetCRL"> <section anchor="GetCertCRL" numbered="true" toc="default">
<t> <name>GetCert and GetCRL</name>
<t>
The messageData for these types consist of an IssuerAndSerialNumber as defined The messageData for these types consist of an IssuerAndSerialNumber, as defined
in CMS which uniquely identifies the certificate being requested, either the in CMS, that uniquely identifies the certificate being requested, either the
certificate itself for GetCert or its revocation status via a CRL for GetCRL. certificate itself for GetCert or its revocation status via a CRL for GetCRL.
In addition the message must contain the the authenticatedAttributes specified In addition, the message must contain the authenticatedAttributes specified
in <xref target="signed-attrs"/>. in <xref target="signed-attrs" format="default"/>.
</t> </t>
<t> <t>
These message types, while included here for completeness, apply unnecessary These message types, while included here for completeness, apply unnecessary
cryptography and messaging overhead to the simple task of transferring a cryptography and messaging overhead to the simple task of transferring a
certificate or CRL (see <xref target="security-unnecessary"/>). certificate or CRL (see <xref target="security-unnecessary" format="default"/>).
Implementations SHOULD prefer Implementations <bcp14>SHOULD</bcp14> prefer
<xref target="HTTP-certstore">HTTP certificate-store access</xref> or LDAP <xref target="RFC4387" format="default">HTTP certificate-store access</xref> or
LDAP
over the use of these messages. over the use of these messages.
</t> </t>
</section> </section>
</section> </section>
<section anchor="certs-only" title="Degenerate certificates-only CMS Signe <section anchor="certs-only" numbered="true" toc="default">
d-Data"> <name>Degenerate certificates-only CMS SignedData</name>
<t>
CMS includes a degenerate case of the Signed-Data content type in which there <t>
CMS includes a degenerate case of the SignedData content type in which there
are no signers. The use of such a degenerate case is to disseminate 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 certificates and CRLs. For SCEP, the content field of the ContentInfo value of
a degenerate certificates-only Signed-Data MUST be omitted. When carrying a degenerate certificates-only SignedData <bcp14>MUST</bcp14> be omitted. When
certificates, the certificates are included in the 'certificates' field of the carrying
Signed-Data. When carrying a CRL, the CRL is included in the 'crls' field of certificates, the certificates are included in the certificates field of the
the Signed-Data. SignedData. When carrying a CRL, the CRL is included in the crls field of
the SignedData.
</t> </t>
</section> </section>
<section anchor="CA-caps" title="CA Capabilities"> <section anchor="CA-caps" numbered="true" toc="default">
<name>CA Capabilities</name>
<t> <t>
In order to provide support for future enhancements to the protocol, CAs MUST In order to provide support for future enhancements to the protocol, CAs <bcp14> MUST</bcp14>
implement the GetCACaps message to allow clients to query which functionality implement the GetCACaps message to allow clients to query which functionality
is available from the CA. is available from the CA.
</t> </t>
<section anchor="CA-caps-HTTP" title="GetCACaps HTTP Message Format"> <section anchor="CA-caps-HTTP" numbered="true" toc="default">
<name>GetCACaps HTTP Message Format</name>
<figure> <t>This message requests capabilities from a CA, with the
<preamble>This message requests capabilities from a CA, with format as described in <xref target="HTTP-GET-POST" format="default"/>:
the </t>
format:</preamble>
<artwork><![CDATA[
<sourcecode type="">
"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
</sourcecode>
]]></artwork> </section>
</figure>
<t>
as described in <xref target="HTTP-GET-POST"/>.
</t>
</section>
<section anchor="CA-caps-resp" title="CA Capabilities Response Format
">
<texttable align="left"> <section anchor="CA-caps-resp" numbered="true" toc="default">
<preamble>The response for a GetCACaps message is a list of C <name>CA Capabilities Response Format</name>
A <t>The response for a GetCACaps message is a list of CA
capabilities, in plain text and in any order, separated capabilities, in plain text and in any order, separated
by &lt;CR&gt;&lt;LF&gt; or &lt;LF&gt; c haracters. This by &lt;CR&gt;&lt;LF&gt; or &lt;LF&gt; c haracters. This
specification defines the following key words (quotation specification defines the following key words (quotation
marks are not sent):</preamble> marks are not sent):</t>
<ttcol>Keyword</ttcol> <table align="left" anchor="keywords">
<ttcol>Description</ttcol> <name>GetCACaps Response Keywords</name>
<thead>
<c>"AES"</c><c>CA supports the AES128-CBC encryption <tr>
algorithm.</c> <th align="left">Keyword</th>
<th align="left">Description</th>
<c>"DES3"</c><c>CA supports the triple DES-CBC encryption </tr>
algorithm.</c> </thead>
<tbody>
<c>"GetNextCACert"</c><c>CA supports the GetNextCACert <tr>
message.</c> <td align="left">AES</td>
<td align="left">CA supports the AES128-CBC encryption
<c>"POSTPKIOperation"</c><c>CA supports PKIOPeration messages algorithm.</td>
sent </tr>
via HTTP POST.</c> <tr>
<td align="left">DES3</td>
<c>"Renewal"</c><c>CA supports the Renewal CA operation.</c> <td align="left">CA supports the triple DES-CBC encryption
algorithm.</td>
<c>"SHA-1"</c><c>CA supports the SHA-1 hashing algorithm.</c> </tr>
<tr>
<c>"SHA-256"</c><c>CA supports the SHA-256 hashing algorithm. <td align="left">GetNextCACert</td>
</c> <td align="left">CA supports the GetNextCACert
message.</td>
<c>"SHA-512"</c><c>CA supports the SHA-512 hashing algorithm. </tr>
</c> <tr>
<td align="left">POSTPKIOperation</td>
<c>"SCEPStandard"</c><c>CA supports all mandatory-to-implemen <td align="left">CA supports PKIOPeration messages sent
t via HTTP POST.</td>
</tr>
<tr>
<td align="left">Renewal</td>
<td align="left">CA supports the Renewal CA operation.</td>
</tr>
<tr>
<td align="left">SHA-1</td>
<td align="left">CA supports the SHA-1 hashing algorithm.</td>
</tr>
<tr>
<td align="left">SHA-256</td>
<td align="left">CA supports the SHA-256 hashing algorithm.</td>
</tr>
<tr>
<td align="left">SHA-512</td>
<td align="left">CA supports the SHA-512 hashing algorithm.</td>
</tr>
<tr>
<td align="left">SCEPStandard</td>
<td align="left">CA supports all mandatory-to-implement
sections of the SCEP standard. This keyword implies "AES ", sections of the SCEP standard. This keyword implies "AES ",
"POSTPKIOperation", and "SHA-256", as well as the provisi ons of "POSTPKIOperation", and "SHA-256", as well as the provisi ons of
<xref target="MTI"/>.</c> <xref target="MTI" format="default"/>.</td>
</tr>
</texttable> </tbody>
</table>
<t> <t>
The table above lists all of the keywords that are defined in this <xref target="keywords" /> lists all of the keywords that are defined in this
specification. A CA MAY provide additional keywords advertising further specification. A CA <bcp14>MAY</bcp14> provide additional keywords advertising
capabilities and functionality. A client MUST be able to accept and ignore further
capabilities and functionality. A client <bcp14>MUST</bcp14> be able to accept
and ignore
any unknown keywords that might be sent by a CA. any unknown keywords that might be sent by a CA.
</t>
</t> <t>
<t> The CA <bcp14>MUST</bcp14> use the text case specified here, but clients
<bcp14>SHOULD</bcp14> ignore the text case when processing this message.
The CA MUST use the text case specified here, but clients SHOULD ignore the Clients <bcp14>MUST</bcp14> accept the standard
text case when processing this message. Clients MUST accept the standard HTTP-style text delimited by &lt;CR&gt;&lt;LF&gt; as well as the
HTTP-style &lt;CR&gt;&lt;LF&gt;-delimited text as well as the &lt;LF&gt;- text delimited by &lt;LF&gt; specified in an earlier draft version of this
delimited text specified in an earlier version of this specification. specification.
</t>
</t> <t>
<t> The client <bcp14>SHOULD</bcp14> use SHA-256 in preference to SHA-1 hashing and
AES128-CBC in
The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES128-CBC in
preference to triple DES-CBC if they are supported by the CA. Although the preference to triple DES-CBC 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 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 of interoperability the de facto universal standards of AES128-CBC and SHA-256
SHOULD be used. <bcp14>SHOULD</bcp14> be used.
</t>
</t> <t>
<t> Announcing some of these capabilities individually is redundant, since they're
required as mandatory-to-implement functionality (see <xref target="MTI" format=
Announcing some of these capabilities individually is redundant since they're "default"/>)
required as mandatory-to-implement functionality (see <xref target="MTI"/>) whose presence as a whole is signalled by the "SCEPStandard" capability. However
whose presence as a whole is signalled by the "SCEPStandard" capability, but ,
it may be useful to announce them in order to deal with older implementations it may be useful to announce them in order to deal with older implementations
that would otherwise default to obsolete, insecure algorithms and mechanisms. that would otherwise default to obsolete, insecure algorithms and mechanisms.
</t> </t>
<t> <t>
If the CA supports none of the above capabilities it SHOULD return an empty If the CA supports none of the above capabilities, it <bcp14>SHOULD</bcp14> retu
message. A CA MAY simply return an HTTP error. A client that receives an rn an empty
empty message or an HTTP error SHOULD interpret the response as if none of the message. A CA <bcp14>MAY</bcp14> simply return an HTTP error. A client that re
ceives an
empty message or an HTTP error <bcp14>SHOULD</bcp14> interpret the response as i
f none of the
capabilities listed are supported by the CA. capabilities listed are supported by the CA.
</t> </t>
<t> <t>
Note that at least one widely-deployed server implementation supports several Note that at least one widely deployed server implementation supports several
of the above operations but doesn't support the GetCACaps message to indicate 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 that it supports them, and it will close the connection if sent a GetCACaps
message. This means that the equivalent of GetCACaps must be performed message. This means that the equivalent of GetCACaps must be performed
through server fingerprinting, which can be done using the ID string through server fingerprinting, which can be done using the ID string
"Microsoft-IIS". Newer versions of the same server, if sent a SCEP request "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 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 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 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 addition, the server will generate CA certificates that only have one, but not
both, of the keyEncipherment and digitalSignature keyUsage flags set, both, of the keyEncipherment and digitalSignature keyUsage flags set,
requiring that the client ignore the keyUsage flags in order to use the requiring that the client ignore the keyUsage flags in order to use the
certificates for SCEP. certificates for SCEP.
</t> </t>
<t> <t>
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore The Content-type of the reply <bcp14>SHOULD</bcp14> be "text/plain". Clients
<bcp14>SHOULD</bcp14> ignore
the Content-type, as older implementations of SCEP may send various the Content-type, as older implementations of SCEP may send various
Content-types. Content-types.
</t>
</t> <t>Example:</t>
<figure> <sourcecode>
<preamble>Example:</preamble>
<artwork><![CDATA[
GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1 GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1
</sourcecode>
]]></artwork> <t>might return:</t>
</figure> <sourcecode>
<figure>
<preamble>might return:</preamble>
<artwork><![CDATA[
AES AES
GetNextCACert GetNextCACert
POSTPKIOperation POSTPKIOperation
SCEPStandard SCEPStandard
SHA-256 SHA-256
</sourcecode>
<t>
]]></artwork> This means that the CA supports modern crypto algorithms, and the GetNextCACert
</figure> message allows PKIOperation messages (PKCSReq/RenewalReq, GetCert, CertPoll,
<t> ...) to be sent using HTTP POST and is compliant with the final version of
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. the SCEP standard.
</t> </t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="SCEP-trans" numbered="true" toc="default">
<section anchor="SCEP-trans" title="SCEP Transactions"> <name>SCEP Transactions</name>
<t> <t>
This section describes the SCEP Transactions and their This section describes the SCEP Transactions and their
<xref target="HTTP">HTTP</xref> transport mechanism. <xref target="RFC7230" format="default">HTTP</xref> transport mechanism.
</t> </t>
<t> <t>
Note that SCEP doesn't follow best current practices on usage of HTTP. In Note that SCEP doesn't follow best current practices on usage of HTTP. In
particular it recommends ignoring some Media Types and hardcodes specific URI particular, it recommends ignoring some media types and hard-codes specific URI
paths. Guidance on the appropriate application of HTTP in these circumstances paths. Guidance on the appropriate application of HTTP in these circumstances
may be found in <xref target="BCP56bis"/>. may be found in <xref target="I-D.ietf-httpbis-bcp56bis" format="default"/>.
</t> </t>
<section anchor="HTTP-GET-POST" title="HTTP POST and GET Message Format <section anchor="HTTP-GET-POST" numbered="true" toc="default">
s"> <name>HTTP POST and GET Message Formats</name>
<t> <t>
SCEP uses the HTTP "POST" and "GET" HTTP methods <xref target="HTTP"/> to SCEP uses the HTTP POST and GET methods <xref target="RFC7230" format="default"/ > to
exchange information with the CA. The following defines the ABNF syntax of exchange information with the CA. The following defines the ABNF syntax of
HTTP POST and GET methods sent from a client to a CA: HTTP POST and GET methods sent from a client to a CA:
</t> </t>
<figure> <sourcecode type="abnf">
<artwork><![CDATA[
POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION
SP HTTP-version CRLF SP HTTP-version CRLF
GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
"&message=" MESSAGE SP HTTP-version CRLF "&amp;message=" MESSAGE SP HTTP-version CRLF
</sourcecode>
]]></artwork>
</figure>
<t>
where:
</t>
<t> <t>
where:
<list style="symbols">
<t>SCEPPATH is the HTTP URL path for accessing the CA. Clients
SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe
"
unless directed to do otherwise by the CA.</t>
<t>OPERATION depends on the SCEP transaction and is defined in
the
following sections.</t>
<t>HTTP-version is the HTTP version string, which is "HTTP/1.1"
for
<xref target="HTTP"/>.</t>
<t>SP and CRLF are space and carriage return/linefeed as define
d in
<xref target="ABNF"/>.</t>
</list>
</t> </t>
<ul spacing="compact">
<li>SCEPPATH is the HTTP URL path for accessing the CA. Clients
<bcp14>SHOULD</bcp14> set SCEPPATH to the fixed string "/cgi-bi
n/pkiclient.exe"
unless directed to do otherwise by the CA.</li>
<li>OPERATION depends on the SCEP transaction and is defined in the
following sections.</li>
<li>HTTP-version is the HTTP version string, which is "HTTP/1.1" for
<xref target="RFC7230" format="default"/>.</li>
<li>SP and CRLF are space and carriage return/linefeed, as defined in
<xref target="RFC5234" format="default"/>.</li>
</ul>
<t> <t>
The CA will typically ignore SCEPPATH since it's unlikely to be issuing The CA will typically ignore SCEPPATH, since it's unlikely to be issuing
certificates via a web server. Clients SHOULD set SCEPPATH to the fixed certificates via a web server. Clients <bcp14>SHOULD</bcp14> set SCEPPATH to th
e fixed
string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA. string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA.
The CA SHOULD ignore the SCEPPATH unless its precise format is critical to the The CA <bcp14>SHOULD</bcp14> ignore the SCEPPATH unless its precise format is cr itical to the
CA's operation. CA's operation.
</t> </t>
<t> <t>
Early SCEP drafts performed all communications via GET messages, including
Early SCEP drafts performed all communications via "GET" messages, including non-idempotent ones that should have been sent via POST messages; see
non-idempotent ones that should have been sent via "POST" messages, see <xref target="I-D.ietf-httpbis-bcp56bis" format="default"/> for details. This h
<xref target="BCP56bis"/> for details. This has caused problems because of as caused problems because of
the way that the (supposedly) idempotent GET interacts with caches and the way that the (supposedly) idempotent GET interacts with caches and
proxies, and because the extremely large GET requests created by encoding CMS proxies, and because the extremely large GET requests created by encoding CMS
messages may be truncated in transit. These issues are typically not visible 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 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 CA supports POST, the CMS-encoded SCEP messages <bcp14>MUST</bcp14> be sent via HTTP POST
instead of HTTP GET. This applies to any SCEP message except GetCACert, instead of HTTP GET. This applies to any SCEP message except GetCACert,
GetNextCACert, and GetCACaps, and avoids the need for base64- and URL-encoding 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 that's required for GET messaging. The client can verify that the CA supports
SCEP messages via POST by looking for the "SCEPStandard" or "POSTPKIOperation" SCEP messages via POST by looking for the "SCEPStandard" or "POSTPKIOperation"
capability (See <xref target="CA-caps-resp"/>). capability (see <xref target="CA-caps-resp" format="default"/>).
</t> </t>
<t> <t>
If a client or CA uses HTTP GET and encounters HTTP-related problems such as 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 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 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 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 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 to update the implementation to use HTTP POST instead. In addition, when using
GET it's recommended to test the implementation from as many different network GET, it's recommended to test the implementation from as many different network
locations as possible to determine whether the use of GET will cause problems locations as possible to determine whether the use of GET will cause problems
with communications. with communications.
</t> </t>
<t> <t>
When using GET messages to communicate binary data, base64 encoding as When using GET messages to communicate binary data, base64 encoding as
specified in <xref target="Base64"/> Section 4 MUST be used. The base64 specified in <xref target="RFC4648" sectionFormat="of" section="4"/>
encoded data is distinct from "base64url" and may contain URI reserved <bcp14>MUST</bcp14> be used. The base64-encoded data is distinct from
characters, thus it MUST be escaped as specified in <xref target="URI"/> in "base64url" and may contain URI reserved
addition to being base64 encoded. Finally, the encoded data is inserted into characters; thus, it <bcp14>MUST</bcp14> be escaped as specified in <xref
target="RFC3986" format="default"/> in addition to being base64 encoded.
Finally, the encoded data is inserted into
the MESSAGE portion of the HTTP GET request. the MESSAGE portion of the HTTP GET request.
</t> </t>
</section> </section>
<section anchor="GetCACert" title="Get CA Certificate"> <section anchor="GetCACert" numbered="true" toc="default">
<t> <name>Get CA Certificate</name>
<t>
To get the CA certificate(s), the client sends a GetCACert message to the CA. 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 The OPERATION <bcp14>MUST</bcp14> be set to "GetCACert". There is no request da ta associated
with this message. with this message.
</t> </t>
<section anchor="GetCACert-resp" title="Get CA Certificate Respon <section anchor="GetCACert-resp" numbered="true" toc="default">
se Message Format"> <name>Get CA Certificate Response Message Format</name>
<t> <t>
The response for GetCACert is different between the case where the CA directly 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 communicates with the client during the enrolment and the case where an
intermediate CA exists and the client communicates with this CA during the intermediate CA exists and the client communicates with this CA during the
enrolment. enrolment.
</t> </t>
<section anchor="GetCACert-resp-format" title="CA Certificate R <section anchor="GetCACert-resp-format" numbered="true" toc="default">
esponse Message Format"> <name>CA Certificate Response Message Format</name>
<t> <t>
If the CA does not have any intermediate CA certificates, the response 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 consists of a single X.509 CA certificate. The response will have a
Content-Type of "application/x-x509-ca-cert". Content-Type of "application/x-x509-ca-cert".
</t> </t>
<figure> <sourcecode>
<artwork><![CDATA[
"Content-Type: application/x-x509-ca-cert" "Content-Type: application/x-x509-ca-cert"
<binary X.509> &lt;binary X.509&gt;
</sourcecode>
]]></artwork> </section>
</figure> <section anchor="GetCACertChain-resp-format" numbered="true" toc="defa
</section> ult">
<section anchor="GetCACertChain-resp-format" title="CA Certific <name>CA Certificate Chain Response Message Format</name>
ate Chain Response Message Format"> <t>
<t>
If the CA has intermediate CA certificates, the response consists of a If the CA has intermediate CA certificates, the response consists of a
degenerate certificates-only CMS Signed-Data message (<xref degenerate certificates-only CMS SignedData message (<xref target="certs-only" f
target="certs-only"/>) containing the certificates, with the intermediate CA ormat="default"/>) containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s). The response will have a 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 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 is used for historical reasons due to its use in older versions of this
specification, no special meaning should be attached to the label. specification -- no special meaning should be attached to the label.
</t>
</t>
<figure>
<artwork><![CDATA[
<sourcecode>
"Content-Type: application/x-x509-ca-ra-cert" "Content-Type: application/x-x509-ca-ra-cert"
<binary CMS> &lt;binary CMS&gt;
</sourcecode>
]]></artwork> </section>
</figure> </section>
</section> </section>
</section> <section anchor="cert-enrolment" numbered="true" toc="default">
</section> <name>Certificate Enrolment/Renewal</name>
<section anchor="cert-enrolment" title="Certificate Enrolment/Renewal"> <t>
<t> A PKCSReq/RenewalReq (<xref target="PKCSReq" format="default"/>) message is used
to perform a
A PKCSReq/RenewalReq (<xref target="PKCSReq"/>) message is used to perform a certificate enrolment or renewal transaction. The OPERATION <bcp14>MUST</bcp14>
certificate enrolment or renewal transaction. The OPERATION MUST be set to be set to
"PKIOperation". Note that when used with HTTP POST, the only OPERATION "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 possible is "PKIOperation", so many CAs don't check this value or even notice
its absence. When implemented using HTTP POST the message is sent with a its absence. When implemented using HTTP POST, the message is sent with a
Content-Type of "application/x-pki-message" and might look as follows: Content-Type of "application/x-pki-message" and might look as follows:
</t>
</t> <sourcecode>
<figure>
<artwork><![CDATA[
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
Content-Length: <length of data&gt; Content-Length: <length of data&gt;
Content-Type: application/x-pki-message Content-Type: application/x-pki-message
<binary CMS data> &lt;binary CMS data&gt;
</sourcecode>
]]></artwork> <t>
</figure> When implemented using HTTP GET, this might look as follows:
<t> </t>
When implemented using HTTP GET this might look as follows:
</t>
<figure>
<artwork><![CDATA[
GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ <sourcecode>
GET /cgi-bin/pkiclient.exe?operation=PKIOperation&amp; \
message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1
</sourcecode>
]]></artwork> <section anchor="cert-enrolment-resp" numbered="true" toc="default">
</figure> <name>Certificate Enrolment/Renewal Response Message</name>
<section anchor="cert-enrolment-resp" title="Certificate Enrolmen <t>
t/Renewal Response Message">
<t>
If the request is granted, a CertRep SUCCESS message If the request is granted, a CertRep SUCCESS message
(<xref target="CertRep-success"/>) is returned. If the request is rejected, a (<xref target="CertRep-success" format="default"/>) is returned. If the request
CertRep FAILURE message (<xref target="CertRep-failure"/>) is returned. If is rejected, a
CertRep FAILURE message (<xref target="CertRep-failure" format="default"/>) is r
eturned. If
the CA is configured to manually authenticate the client, a CertRep PENDING the CA is configured to manually authenticate the client, a CertRep PENDING
message (<xref target="CertRep-pending"/>) MAY be returned. The CA MAY return message (<xref target="CertRep-pending" format="default"/>) <bcp14>MAY</bcp14> b e returned. The CA <bcp14>MAY</bcp14> return
a PENDING for other reasons. a PENDING for other reasons.
</t> </t>
<t> <t>
The response will have a Content-Type of "application/x-pki-message". The response will have a Content-Type of "application/x-pki-message".
</t>
</t> <sourcecode>
<figure>
<artwork><![CDATA[
"Content-Type: application/x-pki-message" "Content-Type: application/x-pki-message"
<binary CertRep message> &lt;binary CertRep message&gt;
</sourcecode>
]]></artwork> </section>
</figure> </section>
</section> <section anchor="poll-resp" numbered="true" toc="default">
</section> <name>Poll for Client Initial Certificate</name>
<section anchor="poll-resp" title="Poll for Client Initial Certificate" <t>
>
<t>
When the client receives a CertRep message with pkiStatus set to PENDING, it 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 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 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 request is rejected or some preconfigured time limit for polling or maximum
number of polls is exceeded. The OPERATION MUST be set to "PKIOperation". number of polls is exceeded. The OPERATION <bcp14>MUST</bcp14> be set to "PKIOp eration".
</t> </t>
<t> <t>
CertPoll messages exchanged during the polling period MUST carry the same CertPoll messages exchanged during the polling period <bcp14>MUST</bcp14> carry the same
transactionID attribute as the previous PKCSReq/RenewalReq. A CA receiving a transactionID attribute as the previous PKCSReq/RenewalReq. A CA receiving a
CertPoll for which it does not have a matching PKCSReq/RenewalReq MUST reject CertPoll for which it does not have a matching PKCSReq/RenewalReq <bcp14>MUST</b cp14> reject
this request. this request.
</t> </t>
<t> <t>
Since at this time the certificate has not been issued, the client can only 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 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 via PKCSReq/RenewalReq) to identify the polled certificate request (but see
the note on identification during polling in <xref target="CertPoll"/>). In the note on identification during polling in <xref target="CertPoll"
theory there can be multiple outstanding requests from one client (for format="default"/>). In
example, if different keys and different key-usages were used to request 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 multiple certificates), so the transactionID must also be included to
disambiguate between multiple requests. In practice however the client SHOULD disambiguate between multiple requests. In practice, however, the client <bcp14
NOT have multiple requests outstanding at any one time, since this tends to >SHOULD
NOT</bcp14> have multiple requests outstanding at any one time, since this tends
to
confuse some CAs. confuse some CAs.
</t> </t>
<section anchor="poll-resp-format" title="Polling Response Messag <section anchor="poll-resp-format" numbered="true" toc="default">
e Format"> <name>Polling Response Message Format</name>
<t> <t>
The response messages for CertPoll are the same as in <xref The response messages for CertPoll are the same as in <xref target="cert-enrolme
target="cert-enrolment-resp"/>. nt-resp" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cert-access" title="Certificate Access"> <section anchor="cert-access" numbered="true" toc="default">
<t> <name>Certificate Access</name>
<t>
A client can query an issued certificate from the SCEP CA, as long as the 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 client knows the issuer name and the issuer-assigned certificate serial
number. number.
</t> </t>
<t> <t>
This transaction consists of one GetCert (<xref target="GetCertCRL"/>) message This transaction consists of one GetCert (<xref target="GetCertCRL" format="defa
sent to the CA by a client, and one CertRep (<xref target="CertRep"/>) message ult"/>) message
sent back from the CA. The OPERATION MUST be set to "PKIOperation". sent to the CA by a client and one CertRep (<xref target="CertRep" format="defau
lt"/>) message
sent back from the CA. The OPERATION <bcp14>MUST</bcp14> be set to "PKIOperatio
n".
</t> </t>
<section anchor="cert-access-resp" title="Certificate Access Resp <section anchor="cert-access-resp" numbered="true" toc="default">
onse Message Format"> <name>Certificate Access Response Message Format</name>
<t> <t>
In this case, the CertRep from the CA is same as in <xref In this case, the CertRep from the CA is same as in <xref target="cert-enrolment
target="cert-enrolment-resp"/>, except that the CA will either grant the -resp" format="default"/>, except that the CA will either grant the
request (SUCCESS) or reject it (FAILURE). request (SUCCESS) or reject it (FAILURE).
</t> </t>
</section> </section>
</section> </section>
<section anchor="CRL-access" title="CRL Access"> <section anchor="CRL-access" numbered="true" toc="default">
<t> <name>CRL Access</name>
<t>
Clients can request a CRL from the SCEP CA as described in <xref Clients can request a CRL from the SCEP CA, as described in <xref
target="overview-CRL-access"/>. The OPERATION MUST be set to "PKIOperation". target="overview-CRL-access" format="default"/>. The OPERATION
<bcp14>MUST</bcp14> be set to "PKIOperation".
</t> </t>
<section anchor="CRL-access-resp" title="CRL Access Response Mess <section anchor="CRL-access-resp" numbered="true" toc="default">
age Format"> <name>CRL Access Response Message Format</name>
<t> <t>
The CRL is sent back to the client in a CertRep (<xref target="CertRep"/>) The CRL is sent back to the client in a CertRep (<xref target="CertRep" format=" default"/>)
message. The information portion of this message is a degenerate message. The information portion of this message is a degenerate
certificates-only Signed-Data (<xref target="certs-only"/>) that contains only certificates-only SignedData (<xref target="certs-only"
the most recent CRL in the crls field of the Signed-Data. format="default"/>) that contains only
the most recent CRL in the crls field of the SignedData.
</t> </t>
</section> </section>
</section> </section>
<section anchor="get-next-CA" title="Get Next Certificate Authority Cer <section anchor="get-next-CA" numbered="true" toc="default">
tificate"> <name>Get Next Certificate Authority Certificate</name>
<t> <t>
When a CA certificate is about to expire, clients need to retrieve the CA's 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 next CA certificate (i.e., the rollover certificate). This is done via the
GetNextCACert message. The OPERATION MUST be set to "GetNextCACert". There GetNextCACert message. The OPERATION <bcp14>MUST</bcp14> be set to "GetNextCACe
rt". There
is no request data associated with this message. is no request data associated with this message.
</t> </t>
<section anchor="get-next-CA-format" title="Get Next CA Response <section anchor="get-next-CA-format" numbered="true" toc="default">
Message Format"> <name>Get Next CA Response Message Format</name>
<t> <t>
The response consists of a Signed-Data CMS message, signed by the current CA The response consists of a SignedData CMS message, signed by the current CA
signing key. Clients MUST validate the signature on the message before signing key. Clients <bcp14>MUST</bcp14> validate the signature on the message
before
trusting any of its contents. The response will have a Content-Type of trusting any of its contents. The response will have a Content-Type of
"application/x-x509-next-ca-cert". "application/x-x509-next-ca-cert".
</t>
</t> <sourcecode>
<figure>
<artwork><![CDATA[
"Content-Type: application/x-x509-next-ca-cert" "Content-Type: application/x-x509-next-ca-cert"
<binary CMS> &lt;binary CMS&gt;
</sourcecode>
]]></artwork> <t>
</figure>
<t>
The content of the Signed-Data message is a degenerate certificates-only The content of the SignedData message is a degenerate certificates-only
Signed-Data message (<xref target="certs-only"/>) containing the new CA SignedData message (<xref target="certs-only" format="default"/>) containing the
new CA
certificate(s) to be used when the current CA certificate expires. certificate(s) to be used when the current CA certificate expires.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<!-- ======================================================================
-->
<section anchor="state-trans" title="SCEP Transaction Examples">
<t>
The following section gives several examples of client to CA transactions. <section anchor="state-trans" numbered="true" toc="default">
Client actions are indicated in the left column, CA actions are indicated in <name>SCEP Transaction Examples</name>
the right column, and the transactionID is given in parentheses (for ease of <t>
reading small integer values have been used, in practice full transaction IDs
would be used). The first transaction, for example, would read like this:
</t> The following section gives several examples of client-to-CA transactions.
<t> Client actions are indicated in the left column, CA actions are indicated in
the right column, and the transactionID is given in parentheses. For ease of
reading, small integer values have been used; in practice, full transaction IDs
would be used. The first transaction, for example, would read like this:
"Client Sends PKCSReq message with transactionID 1 to the CA. The CA signs </t>
<blockquote>
Client Sends PKCSReq message with transactionID 1 to the CA. The CA signs
the certificate and constructs a CertRep Message containing the signed the certificate and constructs a CertRep Message containing the signed
certificate with a transaction ID 1. The client receives the message and certificate with a transaction ID 1. The client receives the message and
installs the certificate locally". installs the certificate locally.
</blockquote>
</t> <section numbered="true" toc="default">
<section title="Successful Transactions"> <name>Successful Transactions</name>
<figure>
<figure> <name>Successful Enrolment Case: Automatic Processing</name>
<preamble>Successful Enrolment Case: Automatic processing</prea <artwork name="" type="" align="left" alt=""><![CDATA[
mble>
<artwork><![CDATA[
PKCSReq (1) ----------> CA issues certificate PKCSReq (1) ----------> CA issues certificate
<---------- CertRep (1) SUCCESS <---------- CertRep (1) SUCCESS
Client installs certificate Client installs certificate
]]></artwork> ]]></artwork>
</figure> </figure>
<figure>
<preamble>Successful Enrolment Case: Manual authentication
required</preamble>
<artwork><![CDATA[
<figure>
<name>Successful Enrolment Case: Manual Authentication Required</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (2) ----------> Cert request goes into queue PKCSReq (2) ----------> Cert request goes into queue
<---------- CertRep (2) PENDING <---------- CertRep (2) PENDING
CertPoll (2) ----------> Still pending CertPoll (2) ----------> Still pending
<---------- CertRep (2) PENDING <---------- CertRep (2) PENDING
CertPoll (2) ----------> CA issues certificate CertPoll (2) ----------> CA issues certificate
<---------- CertRep (2) SUCCESS <---------- CertRep (2) SUCCESS
Client installs certificate Client installs certificate
]]></artwork> ]]></artwork>
</figure> </figure>
<figure>
<preamble>CA certificate rollover case:</preamble>
<artwork><![CDATA[
<figure>
<name>CA Certificate Rollover Case</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
GetNextCACert ----------> GetNextCACert ---------->
<---------- New CA certificate <---------- New CA certificate
PKCSReq* ----------> CA issues certificate with PKCSReq* ----------> CA issues certificate with
new key new key
<---------- CertRep SUCCESS <---------- CertRep SUCCESS
Client stores certificate Client stores certificate
for installation when for installation when
existing certificate expires. existing certificate expires.
]]></artwork> ]]></artwork>
<postamble>* Enveloped for the new CA certificate. The CA will </figure>
use
the envelope to determine which key to
use to issue the
client certificate.</postamble>
</figure>
</section> <t>* Enveloped for the new CA certificate. The CA will use
<section title="Transactions with Errors"> the envelope to determine which key to
<t> use to issue the
client certificate.</t>
</section>
<section numbered="true" toc="default">
<name>Transactions with Errors</name>
<t>
In the case of polled transactions that aren't completed automatically, there In the case of polled transactions that aren't completed automatically, there
are two potential options for dealing with a transaction that's interrupted 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 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 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 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 by sending a new PKCSReq/RenewalReq, rather than continuing the previous
CertPoll. Both options have their own advantages and disadvantages. CertPoll. Both options have their own advantages and disadvantages.
</t> </t>
<t> <t>
The CertPoll continuation requires that the client maintain its transaction The CertPoll continuation requires that the client maintain its transaction
state for the time when it resumes polling. This is relatively simple if the 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 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 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 connection as the end of a transaction, so that a new connection followed by a
CertPoll will be treated as an error. CertPoll will be treated as an error.
</t> </t>
<t> <t>
The PKCSReq/RenewalReq continuation doesn't require any state to be maintained 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 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, the certificate was successfully issued but the client never received it,
since the resumed transaction attempt will appear to be a request for a since the resumed transaction attempt will appear to be a request for a
duplicate certificate (see <xref target="security-no-conf"/> for more on why duplicate certificate (see <xref target="security-no-conf" format="default"/> fo
this is a problem). In this case the CA may refuse the transaction, or r 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 require manual intervention to remove/revoke the previous certificate before
the client can request another one. the client can request another one.
</t> </t>
<t> <t>
Since the new-transaction resume is more robust in the presence of errors and 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 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 <bcp14>SHOULD</bcp14> use the new-transaction option in preference to the resume d-CertPoll
option to recover from errors. option to recover from errors.
</t> </t>
<t>Resync Case 1: Client resyncs via new PKCSReq
<figure> (recommended):</t>
<preamble>Resync Case 1: Client resyncs via new PKCSReq <figure>
(recommended):</preamble> <name>Resync Case 1</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (3) ----------> Cert request goes into queue PKCSReq (3) ----------> Cert request goes into queue
<---------- CertRep (3) PENDING <---------- CertRep (3) PENDING
CertPoll (3) ----------> Still pending CertPoll (3) ----------> Still pending
X-------- CertRep(3) PENDING X-------- CertRep(3) PENDING
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
PKCSReq (4) ----------> PKCSReq (4) ---------->
<---------- CertRep (4) PENDING <---------- CertRep (4) PENDING
etc... etc...
]]></artwork> ]]></artwork>
</figure> </figure>
<figure>
<preamble>Resync Case 2: Client resyncs via resumed CertPoll af
ter a
network outage (not recommended, use PKCS
Req to
resync):</preamble>
<artwork><![CDATA[
<t>Resync Case 2: Client resyncs via resumed CertPoll after a
network outage (not recommended; use PKCS
Req to
resync):</t>
<figure>
<name>Resync Case 2</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (5) ----------> Cert request goes into queue PKCSReq (5) ----------> Cert request goes into queue
<---------- CertRep (5) PENDING <---------- CertRep (5) PENDING
CertPoll (5) ----------> Still pending CertPoll (5) ----------> Still pending
X-------- CertRep(5) PENDING X-------- CertRep(5) PENDING
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
CertPoll (5) ----------> CA issues certificate CertPoll (5) ----------> CA issues certificate
<---------- CertRep (5) SUCCESS <---------- CertRep (5) SUCCESS
Client installs certificate Client installs certificate
]]></artwork> ]]></artwork>
</figure> </figure>
<figure> <t>Resync Case 3: Special-case variation of Case 2 where the
<preamble>Resync Case 3: Special-case variation of case 2 where
the
CertRep SUCCESS rather than the CertRep P ENDING is CertRep SUCCESS rather than the CertRep P ENDING is
lost (recommended):</preamble> lost (recommended):</t>
<artwork><![CDATA[ <figure>
<name>Resync Case 3</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (6) ----------> Cert request goes into queue PKCSReq (6) ----------> Cert request goes into queue
<---------- CertRep (6) PENDING <---------- CertRep (6) PENDING
CertPoll (6) ----------> Still pending CertPoll (6) ----------> Still pending
<---------- CertRep (6) PENDING <---------- CertRep (6) PENDING
CertPoll (6) ----------> CA issues certificate CertPoll (6) ----------> CA issues certificate
X-------- CertRep(6) SUCCESS X-------- CertRep(6) SUCCESS
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
PKCSReq (7) ----------> There is already a valid PKCSReq (7) ----------> There is already a valid
certificate with this DN. certificate with this
Distinguished Name (DN).
<---------- CertRep (7) FAILURE <---------- CertRep (7) FAILURE
Admin revokes certificate Admin revokes certificate
PKCSReq (8) ----------> CA issues new certificate PKCSReq (8) ----------> CA issues new certificate
<---------- CertRep (8) SUCCESS <---------- CertRep (8) SUCCESS
Client installs certificate Client installs certificate
]]></artwork> ]]></artwork>
</figure> </figure>
<figure> <t>Resync Case 4: Special-case variation of Case 1 where the
<preamble>Resync Case 4: Special-case variation of case 1 where
the
CertRep SUCCESS rather than the CertRep P ENDING is lost CertRep SUCCESS rather than the CertRep P ENDING is lost
(not recommended, use PKCSReq to resync): (not recommended; use PKCSReq to resync):
</preamble> </t>
<artwork><![CDATA[ <figure>
<name>Resync Case 4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (9) ----------> Cert request goes into queue PKCSReq (9) ----------> Cert request goes into queue
<---------- CertRep (9) PENDING <---------- CertRep (9) PENDING
CertPoll (9) ----------> Still pending CertPoll (9) ----------> Still pending
<---------- CertRep (9) PENDING <---------- CertRep (9) PENDING
CertPoll (9) ----------> CA issues certificate CertPoll (9) ----------> CA issues certificate
X-------- CertRep(9) SIGNED CERT X-------- CertRep(9) SIGNED CERT
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
CertPoll (9) ----------> Certificate already issued CertPoll (9) ----------> Certificate already issued
<---------- CertRep (9) SUCCESS <---------- CertRep (9) SUCCESS
skipping to change at line 1968 skipping to change at line 1960
<---------- CertRep (9) PENDING <---------- CertRep (9) PENDING
CertPoll (9) ----------> Still pending CertPoll (9) ----------> Still pending
<---------- CertRep (9) PENDING <---------- CertRep (9) PENDING
CertPoll (9) ----------> CA issues certificate CertPoll (9) ----------> CA issues certificate
X-------- CertRep(9) SIGNED CERT X-------- CertRep(9) SIGNED CERT
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
CertPoll (9) ----------> Certificate already issued CertPoll (9) ----------> Certificate already issued
<---------- CertRep (9) SUCCESS <---------- CertRep (9) SUCCESS
Client installs certificate Client installs certificate
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
As these examples indicate, resumption from an error via a resumed CertPoll is 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 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 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 stateless and is identical for both polled and nonpolled transactions, whereas
a CertPoll resume treats the two differently (a non-polled transaction is a CertPoll resume treats the two differently. (A nonpolled transaction is
resumed with a PKCSReq/RenewalReq, a polled transaction is resumed with a 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 CertPoll.) For this reason, error recovery <bcp14>SHOULD</bcp14> be handled via
a new PKCSReq
rather than a resumed CertPoll. rather than a resumed CertPoll.
</t> </t>
</section> </section>
</section> </section>
<!-- ======================================================================
-->
<section anchor="ack" title="Contributors/Acknowledgements">
<t>
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. The IETF reviewers provided much useful feedback that
helped improve the draft, and in particular spotted a number of things that
were present in SCEP through established practice rather than by being
explicitly described in the text. 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.
</t>
<t>
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.
</t>
</section>
<!-- ======================================================================
-->
<section anchor="iana" title="IANA Considerations">
<t>
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, Simple
Certificate Enrollment Protocol Attributes denoted as id-scep:
</t>
<figure>
<artwork><![CDATA[
id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 }
]]></artwork>
</figure>
<t>
(Editor's note: When the OID is assigned, the values in the OID table in <xref <section anchor="iana" numbered="true" toc="default">
target="pkiMessage"/> will also need to be updated). <name>IANA Considerations</name>
<t>
A object identifier for an arc to assign SCEP Attribute Identifiers has been
assigned in the "SMI Security for PKIX" registry (1.3.6.1.5.5.7). This object
identifer, Simple Certificate Enrollment Protocol Attributes, is denoted as
id-scep:
</t>
</t> <sourcecode>
<t> id-scep OBJECT IDENTIFIER ::= { id-pkix 24 }
</sourcecode>
This assignment created the new SMI Security for SCEP Attribute Identifiers <t>
((1.3.6.1.5.5.7.TBD1) registry with the following entries with references to IANA created the "SMI Security for SCEP Attribute Identifiers" registry
(1.3.6.1.5.5.7.24) with the following entries with references to
this document: this document:
</t>
</t> <sourcecode>
<figure>
<artwork><![CDATA[
id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 } id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }
</sourcecode>
]]></artwork> <t>
</figure>
<t>
Entries in the registry are assigned according to the "Specification Required" Entries in the registry are assigned according to the "Specification Required"
policy defined in <xref target="RFC8126"/>. policy defined in <xref target="RFC8126" format="default"/>.
</t>
</t> <t>
<t> <xref target="messageType" format="default"/> describes an "SCEP Message Type" r
egistry, and
<xref target="messageType"/> describes a SCEP Message Type Registry and <xref target="CA-caps" format="default"/> describes an "SCEP CA Capabilities"
<xref target="CA-caps"/> describes a SCEP CA Capabilities Registry to be registry; these registries are maintained by IANA and define a number of such
maintained by the IANA, defining a number of such code point identifiers. code-point identifiers. Entries in the registry are assigned according
Entries in the registry are to be assigned according to the "Specification to the "Specification Required" policy defined in <xref target="RFC8126" format=
Required" policy defined in <xref target="RFC8126"/>. "default"/>.
</t>
<t>
The SCEP Message Type Registry has columns "Value," "Name," "Description," and
"Reference". The "Value" entry is a small positive integer, with the value
"0" reserved.
</t>
<t>
The SCEP CA Capabilities Registry has columns "Keyword", "Description", and </t>
"Reference". Although implementations SHOULD use the SCEP CA Capabilities <t>
Registry, SCEP is often employed in situations where this isn't possible. In The "SCEP Message Types" registry has "Value", "Name", "Description", and
this case private-use CA capabilities may be specified using a unique prefix "Reference" columns. The "Value" entry is a small positive integer; value
"0" is reserved.
</t>
<t>
The "SCEP CA Capabilities" registry has "Keyword", "Description", and
"Reference" columns. Although implementations <bcp14>SHOULD</bcp14> use the "SC
EP CA Capabilities"
registry, SCEP is often employed in situations where this isn't possible. In
this case, private-use CA capabilities may be specified using a unique prefix
such as an organisation identifier or domain name under the control of the such as an organisation identifier or domain name under the control of the
entity that defines the capability. For example the prefix would be entity that defines the capability. For example, the prefix would be
"Example.com-" and the complete capability would be "Example.com-", and the complete capability would be
"Example.com-CapabilityName". "Example.com-CapabilityName".
</t>
<t>
IANA has registered four media types as defined in this document:
</t>
</t> <ul>
<t> <li>application/x-x509-ca-cert</li>
<li>application/x-x509-ca-ra-cert</li>
This document defines four media types for IANA registration: <li>application/x-x509-next-ca-cert</li>
<li>application/x-pki-message</li>
</t> </ul>
<figure> <t>
<artwork><![CDATA[ Note that these are grandfathered media types registered as per <xref
target="RFC6838" sectionFormat="of" section="A"/>. Templates
"application/x-x509-ca-cert" for registrations are specified below.
"application/x-x509-ca-ra-cert" </t>
"application/x-x509-next-ca-cert"
"application/x-pki-message"
]]></artwork>
</figure>
<t>
Note that these are grandfathered media types registered as per Appendix A of
<xref target="RFC6838"/>. Templates for registrations are specified below.
</t>
<section title="Registration of application/x-x509-ca-cert media type">
<t>
Type name: application
</t>
<t>
Subtype name: x-x509-ca-cert
</t>
<t>
Required parameters: none
</t>
<t>
Optional parameters: none
</t>
<t>
Encoding considerations: binary
</t>
<t>
Security considerations: This media type contains a certificate, see the
Security Considerations section of <xref target="PKIX"/>. There is no
executable content.
</t>
<t>
Interoperability considerations: This is a grandfathered registration of an
alias to application/pkix-cert (basically a single DER encoded Certification
Authority certificate), which is only used in SCEP.
</t>
<t>
Published specification: draft-gutmann-scep-15
</t>
<t>
Applications that use this media type: SCEP uses this media type when
returning a CA certificate.
</t>
<t>
Fragment identifier considerations: N/A
</t>
<t>
Additional information:
</t>
<t>
Deprecated alias names for this type: N/A
</t>
<t>
Magic number(s): none
</t>
<t>
File extension(s): N/A
</t>
<t>
Macintosh file type code(s): N/A
</t>
<t>
Person and email address to contact for further information: See the Authors'
Addresses section of draft-gutmann-scep-15
</t>
<t>
Intended usage: LIMITED USE
</t>
<t>
Restrictions on usage: SCEP protocol
</t>
<t>
Author: See the Authors' Addresses section of draft-gutmann-scep-15
</t>
<t>
Change controller: IETF
</t>
<t>
Provisional registration? No
</t>
</section>
<section title="Registration of application/x-x509-ca-ra-cert media typ
e">
<t>
Type name: application
</t>
<t>
Subtype name: x-x509-ca-ra-cert
</t>
<t>
Required parameters: none
</t>
<t>
Optional parameters: none
</t>
<t>
Encoding considerations: binary
</t>
<t>
Security considerations: This media type consists of a degenerate
certificates-only CMS Signed-Data message (<xref target="certs-only"/>)
containing the certificates, with the intermediate CA certificate(s) as the
leaf certificate(s). There is no executable content.
</t>
<t>
Interoperability considerations: This is a grandfathered registration which
is only used in SCEP.
</t>
<t>
Published specification: draft-gutmann-scep-15
</t>
<t>
Applications that use this media type: SCEP uses this media type when
returning CA Certificate Chain Response.
</t>
<t>
Fragment identifier considerations: N/A
</t>
<t>
Additional information:
</t>
<t>
Deprecated alias names for this type: N/A
</t>
<t>
Magic number(s): none
</t>
<t>
File extension(s): N/A
</t>
<t>
Macintosh file type code(s): N/A
</t>
<t>
Person and email address to contact for further information: See the Authors'
Addresses section of draft-gutmann-scep-15
</t>
<t>
Intended usage: LIMITED USE
</t>
<t>
Restrictions on usage: SCEP protocol
</t>
<t>
Author: See the Authors' Addresses section of draft-gutmann-scep-15
</t>
<t>
Change controller: IETF
</t>
<t>
Provisional registration? no
</t>
</section>
<section title="Registration of application/x-x509-next-ca-cert media t
ype">
<t>
Type name: application <section numbered="true" toc="default">
</t> <name>Registration of the application/x-x509-ca-cert Media Type</name>
<t> <dl>
Subtype name: x-x509-next-ca-cert <dt>Type name:</dt>
</t> <dd>application</dd>
<t> <dt>Subtype name:</dt>
Required parameters: none <dd>x-x509-ca-cert</dd>
</t> <dt>Required parameters:</dt>
<t> <dd>none</dd>
Optional parameters: none <dt>Optional parameters:</dt>
</t> <dd>none</dd>
<t> <dt>Encoding considerations:</dt>
Encoding considerations: binary <dd>binary</dd>
</t> <dt>Security considerations:</dt>
<t> <dd>This media type contains a certificate; see the
Security considerations: This media type consists of a Signed-Data CMS Security Considerations section of <xref target="RFC5280"
message, signed by the current CA signing key. There is no executable content. format="default"/>. There is no executable content.</dd>
</t> <dt>Interoperability considerations:</dt>
<t> <dd>This is a grandfathered registration of an alias to application/pkix-cert
Interoperability considerations: This is a grandfathered registration which is (basically a single DER-encoded Certification Authority certificate), which is
only used in SCEP. only used in SCEP.</dd>
</t> <dt>Published specification:</dt>
<t> <dd>RFC 8894</dd>
Published specification: draft-gutmann-scep-15 <dt>Applications that use this media type:</dt>
</t> <dd>SCEP uses this media type when returning a CA certificate.</dd>
<t> <dt>Fragment identifier considerations:</dt>
Applications that use this media type: SCEP uses this media type when <dd>N/A</dd>
returning a Get Next CA Response. <dt>Additional information:</dt>
</t> <dd><t><br/></t>
<t> <dl>
Fragment identifier considerations: N/A <dt>Deprecated alias names for this type:</dt>
</t> <dd>N/A</dd>
<t> <dt>Magic number(s):</dt>
Additional information: <dd>none</dd>
</t> <dt>File extension(s):</dt>
<t> <dd>N/A</dd>
Deprecated alias names for this type: N/A <dt>Macintosh file type code(s):</dt>
</t> <dd>N/A</dd>
<t> </dl>
Magic number(s): none </dd>
</t> <dt>Person and email address to contact for further information:</dt>
<t> <dd>See the Authors' Addresses section of RFC 8894.</dd>
File extension(s): N/A <dt>Intended usage:</dt>
</t> <dd>LIMITED USE</dd>
<t> <dt>Restrictions on usage:</dt>
Macintosh file type code(s): N/A <dd>SCEP protocol</dd>
</t> <dt>Author:</dt>
<t> <dd>See the Authors' Addresses section of RFC 8894</dd>
Person and email address to contact for further information: See the Authors' <dt>Change controller:</dt>
Addresses section of draft-gutmann-scep-15 <dd>IETF</dd>
</t> <dt>Provisional registration?</dt>
<t> <dd>No</dd>
Intended usage: LIMITED USE </dl>
</t> </section>
<t> <section numbered="true" toc="default">
Restrictions on usage: SCEP protocol <name>Registration of the application/x-x509-ca-ra-cert Media Type</name
</t> >
<t>
Author: See the Authors' Addresses section of draft-gutmann-scep-15
</t>
<t>
Change controller: IETF
</t>
<t>
Provisional registration? no
</t> <dl>
</section> <dt>Type name:</dt>
<section title="Registration of application/x-pki-message media type"> <dd>application</dd>
<t> <dt>Subtype name:</dt>
<dd>x-x509-ca-ra-cert</dd>
<dt>Required parameters:</dt>
<dd>none</dd>
<dt>Optional parameters:</dt>
<dd>none</dd>
<dt>Encoding considerations:</dt>
<dd>binary</dd>
<dt>Security considerations:</dt>
<dd>This media type consists of a degenerate
certificates-only CMS SignedData message (<xref target="certs-only"
format="default"/>) containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s). There is no executable
content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration that is only used in SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type:</dt>
<dd>SCEP uses this media type when returning CA Certificate Chain
Response.</dd>
<dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd>
<dt>Magic number(s):</dt>
<dd>none</dd>
<dt>File extension(s):</dt>
<dd>N/A</dd>
<dt>Macintosh file type code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>See the Authors' Addresses section of RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE</dd>
<dt>Restrictions on usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of RFC 8894.</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>no</dd>
</dl>
</section>
Type name: application <section numbered="true" toc="default">
</t> <name>Registration of the application/x-x509-next-ca-cert Media Type</na
<t> me>
Subtype name: x-pki-message <dl>
</t> <dt>Type name:</dt>
<t> <dd>application</dd>
Required parameters: none <dt>Subtype name:</dt>
</t> <dd>x-x509-next-ca-cert</dd>
<t> <dt>Required parameters:</dt>
Optional parameters: none <dd>none</dd>
</t> <dt>Optional parameters:</dt>
<t> <dd>none</dd>
Encoding considerations: binary <dt>Encoding considerations:</dt>
</t> <dd>binary</dd>
<t> <dt>Security considerations:</dt>
Security considerations: This media type consists of a degenerate <dd>This media type consists of a SignedData CMS message, signed by the
certificates-only CMS Signed-Data message. There is no executable content. current CA signing key. There is no executable content.</dd>
</t> <dt>Interoperability considerations:</dt>
<t> <dd>This is a grandfathered registration that is only used in SCEP.</dd>
Interoperability considerations: This is a grandfathered registration which is <dt>Published specification:</dt>
only used in SCEP. <dd>RFC 8894</dd>
</t> <dt>Applications that use this media type:</dt>
<t> <dd>SCEP uses this media type when returning a Get Next CA response.</dd>
Published specification: draft-gutmann-scep-15 <dt>Fragment identifier considerations:</dt>
</t> <dd>N/A</dd>
<t> <dt>Additional information:</dt>
Applications that use this media type: SCEP uses this media type when <dd><t><br/></t>
returning a Certificate Enrolment/Renewal Response. <dl>
</t> <dt>Deprecated alias names for this type:</dt>
<t> <dd>N/A</dd>
Fragment identifier considerations: N/A <dt>Magic number(s):</dt>
</t> <dd>none</dd>
<t> <dt>File extension(s):</dt>
Additional information: <dd>N/A</dd>
</t> <dt>Macintosh file type code(s):</dt>
<t> <dd>N/A</dd>
Deprecated alias names for this type: N/A </dl>
</t> </dd>
<t> <dt>Person and email address to contact for further information:</dt>
Magic number(s): none <dd>See the Authors' Addresses section of RFC 8894.</dd>
</t> <dt>Intended usage:</dt>
<t> <dd>LIMITED USE </dd>
File extension(s): N/A <dt>Restrictions on usage:</dt>
</t> <dd>SCEP protocol</dd>
<t> <dt>Author:</dt>
Macintosh file type code(s): N/A <dd>See the Authors' Addresses section of RFC 8894.</dd>
</t> <dt>Change controller:</dt>
<t> <dd>IETF</dd>
Person and email address to contact for further information: See the Authors' <dt>Provisional registration?</dt>
Addresses section of draft-gutmann-scep-15 <dd>no</dd>
</t> </dl>
<t> </section>
Intended usage: LIMITED USE
</t>
<t>
Restrictions on usage: SCEP protocol
</t>
<t>
Author: See the Authors' Addresses section of draft-gutmann-scep-15
</t>
<t>
Change controller: IETF
</t>
<t>
Provisional registration? no
</t> <section numbered="true" toc="default">
</section> <name>Registration of the application/x-pki-message Media Type</name>
</section> <dl>
<!-- ====================================================================== <dt>Type name:</dt>
--> <dd>application</dd>
<section anchor="security" title="Security Considerations"> <dt>Subtype name:</dt>
<t> <dd>x-pki-message</dd>
<dt>Required parameters:</dt>
<dd>none</dd>
<dt>Optional parameters:</dt>
<dd>none</dd>
<dt>Encoding considerations:</dt>
<dd>binary</dd>
<dt>Security considerations:</dt>
<dd>This media type consists of a degenerate certificates-only CMS SignedData
message. There is no executable content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration that is only used in SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type:</dt>
<dd>SCEP uses this media type when returning a Certificate Enrolment/Renewal
Response.</dd>
<dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type:</dt>
<dd>N/A</dd>
<dt>Magic number(s):</dt>
<dd>none</dd>
<dt>File extension(s):</dt>
<dd>N/A</dd>
<dt>Macintosh file type code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>See the Authors' Addresses section of RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE</dd>
<dt>Restrictions on usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of RFC 8894.</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>no</dd>
</dl>
</section>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security goal of SCEP is that no adversary can subvert the public 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 key/identity binding from that intended. An adversary is any entity other
than the client and the CA participating in the protocol. than the client and the CA participating in the protocol.
</t>
</t> <t>
<t>
This goal is met through the use of CMS and PKCS #10 encryption and digital 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 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 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 and the SCEP client's public key is authenticated through manual or preshared
secret authentication. secret authentication.
</t>
</t> <section numbered="true" toc="default">
<section title="General Security"> <name>General Security</name>
<t> <t>
Common key-management considerations such as keeping private keys truly Common key-management considerations such as keeping private keys truly
private and using adequate lengths for symmetric and asymmetric keys must be private and using adequate lengths for symmetric and asymmetric keys must be
followed in order to maintain the security of this protocol. This is followed in order to maintain the security of this protocol. This is
especially true for CA keys which, when compromised, compromise the security especially true for CA keys which, when compromised, compromise the security
of all relying parties. of all relying parties.
</t>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Use of the CA private key"> <name>Use of the CA Private Key</name>
<t> <t>
A CA private key is generally meant for, and usually flagged as, being
A CA private key is generally meant for, and is usually flagged as, being
usable for certificate (and CRL) signing exclusively rather than data signing 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 or encryption. The SCEP protocol, however, uses the CA private key to both sign
and optionally encrypt CMS transport messages. This is generally considered and optionally encrypt CMS transport messages. This is generally considered
undesirable as it widens the possibility of an implementation weakness and undesirable, as it widens the possibility of an implementation weakness and
provides an additional location where the private key must be used (and hence 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 is slightly more vulnerable to exposure) and where a side-channel attack might
be applied. be applied.
</t>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="ChallengePassword Shared Secret Value"> <name>ChallengePassword Shared Secret Value</name>
<t> <t>
The security measures that should be applied to the challengePassword shared The security measures that should be applied to the challengePassword shared
secret depend on the manner in which SCEP is employed. In the simplest case, secret depend on the manner in which SCEP is employed. In the simplest case,
with SCEP used to provision devices with certificates in the manufacturing with SCEP used to provision devices with certificates in the manufacturing
facility, the physical security of the facility may be enough to protect the facility, the physical security of the facility may be enough to protect the
certificate issue process with no additional measures explicitly required. In certificate issue process with no additional measures explicitly required. In
general though the security of the issue process depends on the security general, though, the security of the issue process depends on the security
employed around the use of the challengePassword shared secret. While it's employed around the use of the challengePassword shared secret. While it's
not possible to enumerate every situation in which SCEP may be utilised, the not possible to enumerate every situation in which SCEP may be utilised, the
following security measures should be considered. following security measures should be considered.
</t>
<list style="symbols"> <ul spacing="compact">
<t> <li>
The challengePassword, despite its name, shouldn't be a conventional password The challengePassword, despite its name, shouldn't be a conventional password
but a high-entropy shared secret authentication string. Using the base64 but a high-entropy shared-secret authentication string. Using the base64
encoding of a keying value generated or exchanged as part of standard device encoding of a keying value generated or exchanged as part of standard device
authentication protocols like EAP or DNP3 SA makes for a good authentication protocols like the Extensible Authentication Protocol (EAP) or
challengePassword. The use of high-entropy shared secrets is particulary DNP3 Secure Authentication (DNP3-SA) makes for a good
challengePassword. The use of high-entropy shared secrets is particularly
important when the PasswordRecipientInfo option is used to encrypt SCEP important when the PasswordRecipientInfo option is used to encrypt SCEP
messages, see <xref target="message-processing"/>. messages; see <xref target="message-processing" format="default"/>.
</li>
</t>
<t>
<li>
If feasible, the challengePassword should be a one-time value used to If feasible, the challengePassword should be a one-time value used to
authenticate the issue of a single certificate (subsequent certificate authenticate the issue of a single certificate (subsequent certificate
requests will be authenticated by being signed with the initial certificate). requests will be authenticated by being signed with the initial certificate).
If the challengePassword is single-use then the arrival of subsequent requests If the challengePassword is single use, then the arrival of subsequent requests
using the same challengePassword can then be used to indicate a security using the same challengePassword can then be used to indicate a security
breach. breach.
</li>
</t> <li>
<t>
The lifetime of a challengePassword can be limited, so that it can be used The lifetime of a challengePassword can be limited, so that it can be used
during initial device provisioning but will have expired at a later date if an during initial device provisioning but will have expired at a later date if an
attacker manages to compromise the challengePassword value, for example by attacker manages to compromise the challengePassword value -- for example, by
compromising the device that it's stored in. compromising the device that it's stored in.
</li>
</t> <li>
<t> The CA should take appropriate measures to protect the
challengePassword. Examples of possible measures include: physical security
The CA should take appropriate measures to protect the challengePassword, for measures; storing it as a salted iterated hash or equivalent memory-hard
example via physical security measures, or by storing it as a salted iterated function; storing it as a keyed MAC value if it's not being used for
hash or equivalent memory-hard function or as a keyed MAC value if it's not encryption; and storing it in encrypted form if it is being used for encryption.
being used for encryption, or by storing it in encrypted form if it is being </li>
used for encryption. </ul>
</section>
</t>
</list>
</t>
</section>
<section anchor="security-no-conf" title="Lack of Certificate Issue Con
firmation">
<t>
<section anchor="security-no-conf" numbered="true" toc="default">
<name>Lack of Certificate Issue Confirmation</name>
<t>
SCEP provides no confirmation that the issued certificate was successfully SCEP provides no confirmation that the issued certificate was successfully
received and processed by the client. This means that if the CertRep message 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 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 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 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 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 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, the proof of possession that's not present in the case of a renewal operation;
see <xref target="security-no-pop"/>. see <xref target="security-no-pop" format="default"/>.
</t>
</t> </section>
</section> <section anchor="security-getcacaps" numbered="true" toc="default">
<section anchor="security-getcacaps" title="GetCACaps Issues"> <name>GetCACaps Issues</name>
<t> <t>
The GetCACaps response is not authenticated by the CA. This allows an The GetCACaps response is not authenticated by the CA. This allows an
attacker to perform downgrade attacks on the cryptographic capabilities of the attacker to perform downgrade attacks on the cryptographic capabilities of the
client/CA exchange. In particular if the server were to support MD5 and 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 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 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 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 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 MD5 chosen-prefix collisions can be calculated for a few tens of cents of
computing time using tools like HashClash. It is for this reason that this computing time using tools like HashClash. It is for this reason that this
specification makes single DES and MD5 a MUST NOT feature. Note that all specification makes single DES and MD5 a <bcp14>MUST NOT</bcp14> feature. Note that all
known servers support at least triple DES and SHA-1 (regardless of whether known servers support at least triple DES and SHA-1 (regardless of whether
"DES3" and "SHA-1" are indicated in GetCACaps), so there should never be a "DES3" and "SHA-1" are indicated in GetCACaps), so there should never be a
reason to fall all the way back to single DES and MD5. reason to fall all the way back to single DES and MD5.</t>
<t>
One simple countermeasure to a GetCACaps downgrade attack is for clients that One simple countermeasure to a GetCACaps downgrade attack is for clients that
are operating in an environment where on-path attacks are possible and that are operating in an environment where on-path attacks are possible and that
expect the "SCEPStandard" capability to be indicated by the CA but don't see expect the "SCEPStandard" capability to be indicated by the CA but don't see
it in the GetCACaps response to treat its absence as a security issue, and it in the GetCACaps response to treat its absence as a security issue, and
either discontinue the exchange or continue as if "SCEPStandard" had been either discontinue the exchange or continue as if "SCEPStandard" had been
returned. This requires a certain tradeoff between compatibility with old returned. This requires a certain trade-off between compatibility with old
servers and security against active attacks. servers and security against active attacks.
</t>
</t> </section>
</section> <section anchor="security-no-pop" numbered="true" toc="default">
<section anchor="security-no-pop" title="Lack of PoP in Renewal Request <name>Lack of PoP in Renewal Requests</name>
s"> <t>
<t>
Renewal operations (but not standard certificate-issue operations) are Renewal operations (but not standard certificate-issue operations) are
processed via a previously-issued certificate and its associated private key, 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 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 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 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 recertify 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 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 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, certificate rather than the original signer's certificate. This, and other,
attacks are described in <xref target="ESS">S/MIME ESS</xref>. attacks are described in <xref target="RFC2634" format="default">S/MIME ESS</xre
f>.
</t> </t>
<t> <t>
Avoiding these types of attacks requires situation-specific measures. For Avoiding these types of attacks requires situation-specific measures. For
example CMS/SMIME implementations may use the ESSCertID attribute from <xref example, CMS/SMIME implementations may use the ESSCertID attribute from <xref
target="ESS">S/MIME ESS</xref> or its successor <xref target="ESSv2">S/MIME target="RFC2634" format="default">S/MIME ESS</xref> or its successor, <xref
ESSv2</xref> to unambiguously identify the signing certificate. However since target="RFC5035" format="default">S/MIME
ESSv2</xref>, to unambiguously identify the signing certificate. However, since
other mechanisms and protocols that the certificates will be used with other mechanisms and protocols that the certificates will be used with
typically don't defend against this problem, it's unclear whether this is an typically don't defend against this problem, it's unclear whether this is an
actual issue with SCEP. actual issue with SCEP.
</t>
</t> </section>
</section> <section anchor="traffic-monitoring" numbered="true" toc="default">
<section anchor="traffic-monitoring" title="Traffic Monitoring"> <name>Traffic Monitoring</name>
<t> <t>
SCEP messages are signed with certificates that may contain identifying SCEP messages are signed with certificates that may contain identifying
information. If these are sent over the public Internet and real identity information. If these are sent over the public Internet and real identity
information (rather than placeholder values or arbitrary device IDs) are information (rather than placeholder values or arbitrary device IDs) is
included in the signing certificate data, an attacker may be able to monitor included in the signing certificate data, an attacker may be able to monitor
the identities of the entities submitting the certificate requests. If this the identities of the entities submitting the certificate requests. If this
is an issue then <xref target="RFC7258"/> should be consulted for guidance. is an issue, then <xref target="RFC7258" format="default"/> should be consulted
for guidance.
</t> </t>
</section> </section>
<section anchor="security-unnecessary" title="Unnecessary cryptography" <section anchor="security-unnecessary" numbered="true" toc="default">
> <name>Unnecessary Cryptography</name>
<t> <t>
Some of the SCEP exchanges use unnecessary signing and encryption operations. Some of the SCEP exchanges use unnecessary signing and encryption operations.
In particular the GetCert and GetCRL exchanges are encrypted and signed in In particular, the GetCert and GetCRL exchanges are encrypted and signed in
both directions. The information requested is public and thus encrypting the both directions. The information requested is public, and thus encrypting the
requests is of questionable value. In addition CRLs and certificates sent in 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 responses are already signed by the CA and can be verified by the recipient
without requiring additional signing and encryption. More lightweight means without requiring additional signing and encryption. More lightweight means
of retrieving certificates and CRLs such as <xref target="HTTP-certstore">HTTP of retrieving certificates and CRLs such as <xref target="RFC4387" format="defau lt">HTTP
certificate-store access</xref> and LDAP are recommended for this reason. certificate-store access</xref> and LDAP are recommended for this reason.
</t>
</t> </section>
</section> <section anchor="security-sha1" numbered="true" toc="default">
<section anchor="security-sha1" title="Use of SHA-1"> <name>Use of SHA-1</name>
<t> <t>
The majority of the large number of devices that use SCEP today default to
The majority 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 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 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 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 fully general this. The first is that attacking SCEP would require creating a fully general
SHA-1 collision in close to real time alongside breaking AES (more SHA-1 collision in close to real time alongside breaking AES (more
specifically, it would require creating a fully general SHA-1 collision for specifically, it would require creating a fully general SHA-1 collision for
the PKCS #10 request, breaking the AES encryption around the PKCS #10 request, the PKCS #10 request, breaking the AES encryption around the PKCS #10 request,
and then creating a second SHA-1 collision for the signature on the encrypted and then creating a second SHA-1 collision for the signature on the encrypted
data), which won't be feasible for a long time. data), which won't be feasible for a long time.
</t>
</t> <t>
<t> The second reason is that the signature over the message -- in other words, the
SHA-1 hash that isn't protected by encryption -- doesn't serve any critical
The second reason is that the signature over the message, in other words the
SHA-1 hash that isn't protected by encryption, doesn't serve any critical
cryptographic purpose: The PKCS #10 data itself is authenticated through its cryptographic purpose: The PKCS #10 data itself is authenticated through its
own signature, protected by encryption, and the overall request is authorised own signature, protected by encryption, and the overall request is authorised
by the (encrypted) shared secret. The sole exception to this will be the by the (encrypted) shared secret. The sole exception to this will be the
small number of implementations that support the Renewal operation, which may small number of implementations that support the Renewal operation, which may
be authorised purely through a signature, but presumably any implementation be authorised purely through a signature, but presumably any implementation
recent enough to support Renewal also supports SHA-2. Any legacy recent enough to support Renewal also supports SHA-2. Any legacy
implementation that supports the historic core SCEP protocol would not be implementation that supports the historic core SCEP protocol would not be
affected. affected.
</t>
</t> <t>
<t>
The third reason is that SCEP uses the same key for encryption and signing, so 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 that even if an attacker were able to capture an outgoing renewal request that
didn't include a shared secret (in other words one that was only authorised didn't include a shared secret (in other words, one that was only authorised
through a signature), break the AES encryption, forge the SHA-1 hash in real through a signature), break the AES encryption, forge the SHA-1 hash in real
time, and forward the forged request to the CA, they couldn't decrypt the 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 returned certificate, which is protected with the same key that was used to
generate the signature. While <xref target="security-unnecessary"/> points generate the signature. While <xref target="security-unnecessary" format="defau lt"/> points
out that SCEP uses unnecessary cryptography in places, the additional level of 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 security provided by the extra crypto makes it immune to any issues with
SHA-1. SHA-1.
</t>
</t> <t>
<t>
This doesn't mean that SCEP implementations should continue to use SHA-1 in 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. perpetuity, merely that there's no need for a panicked switch to SHA-2.
</t>
</section>
</t> <section title="Use of HTTP">
</section> <t>
SCEP is an encrypted, authenticated certificate enrollment protocol that uses
HTTP as a simple transport mechanism. Since SCEP messages are already
cryptographically secured, it does not require transport layer security. Where
HTTPS is elected, a performance hit may result from the TLS overhead,
operational problems may result due to the more complex configuration, and
potential security vulnerability may result due to the addition of an entire
TLS protocol stack alongside the basic SCEP protocol.
</t>
<t>
In particular, experience has shown that the issue of configuring
certificates, CAs, and trust for both TLS and SCEP often leads to
interoperability problems because different certificates and trust models are
used in each. Use of HTTPS to authenticate the server does not enable
omission of the ChallengePassword or similar authenticator in the SCEP message
on the assumption that using HTTPS instead of HTTP will somehow make this
insecure usage secure again. HTTPS is not soy sauce for security and is
unnecessary for SCEP, which uses cryptographically secured messages and does
not require transport layer security.
</t>
</section> </section>
<!-- ====================================================================== </section>
-->
</middle>
<!-- ========================================================================
-->
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Re
quirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2119.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc2
119.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc211
9.xml' />
</reference>
<reference anchor='RFC6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Oracle</organization>
</author>
<author initials='J.' surname='Klensin' fullname='John Klensin'>
</author>
<author initials='T.' surname='Hansen' fullname='Tony Hansen'>
<organization>ATT Laboratories</organization>
</author>
<date year='2013' month='January' />
</front>
<seriesInfo name='RFC' value='6838' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc6838.txt' />
</reference>
<reference anchor='RFC7258'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</
title>
<author initials='S.' surname='Farrell' fullname='Stephen Farrell'>
<organization>Trinity College Dublin</organization>
</author>
<author initials='H.' surname='Tschofenig' fullname='Hannes Tschofenig
'>
<organization>ARM Ltd.</organization>
</author>
<date year='2014' month='May' />
</front>
<seriesInfo name='RFC' value='7258' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc7258.txt' />
</reference>
<reference anchor='RFC8126'> </middle>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</
title>
<author initials='B.' surname='Leiba' fullname='Barry Leiba'>
<organization>Huawei Technologies</organization>
</author>
<author initials='T.' surname='Narten' fullname='Thomas Narten'>
<organization>IBM Corporation</organization>
</author>
<date year='2017' month='June' />
</front>
<seriesInfo name='RFC' value='8126' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc8126.txt' />
</reference>
<reference anchor='RFC8174'> <back>
<front> <displayreference target="I-D.ietf-httpbis-bcp56bis" to="HTTP" />
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<author initials='B.' surname='Leiba' fullname='Barry Leiba'>
<organization>Huawei Technologies</organization>
</author>
<date year='2017' month='May' />
</front>
<seriesInfo name='RFC' value='8174' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc8174.txt' />
</reference>
<reference anchor='ABNF'> <references>
<front> <name>References</name>
<title>Augmented BNF for Syntax Specifications: ABNF</title> <references>
<author initials="R" surname="Crocker"></author> <name>Normative References</name>
<author initials="P" surname="Overell"></author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<date year='2008' month='January' /> ence.RFC.2119.xml"/>
</front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name='RFC' value='5234' /> ence.RFC.6838.xml"/>
<format type='TXT' target='http://www.ietf.org/rfc/rfc5234.txt' /> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</reference> ence.RFC.7258.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5234.xml"/>
<reference anchor="AES"> <reference anchor="AES">
<front> <front>
<title>The Advanced Encryption Standard (AES)</title> <title>The Advanced Encryption Standard (AES)</title>
<author fullname='U.S. National Institute of Standards and Technology' <seriesInfo name="FIPS" value="197"/>
> <author fullname="U.S. National Institute of Standards and Technolog
y">
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<date year='2001' month='November' /> <date year="2001" month="November"/>
</front> </front>
<seriesInfo name='FIPS' value='197' /> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197" />
</reference> </reference>
<reference anchor="SHA2"> <reference anchor="SHA2">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<author fullname='U.S. National Institute of Standards and Technology' <seriesInfo name="FIPS" value="180-3"/>
> <author fullname="U.S. National Institute of Standards and Technolog
y">
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<date year='2008' month='October' /> <date year="2008" month="October"/>
</front> </front>
<seriesInfo name='FIPS' value='180-3' /> </reference>
</reference>
<reference anchor='Base64'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S" surname="Josefsson"></author>
<date year='2006' month='October' />
</front>
<seriesInfo name='RFC' value='4648' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4648.txt' />
</reference>
<reference anchor='CMS'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials="R" surname="Housley"></author>
<date year='2009' month='September' />
</front>
<seriesInfo name='RFC' value='5652' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5652.txt' />
</reference>
<reference anchor='HTTP'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Rout
ing</title>
<author initials="R" surname="Fielding"></author>
<author initials="J" surname="Reschke"></author>
<date year='2014' month='June' />
</front>
<seriesInfo name='RFC' value='7230' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc7230.txt' />
</reference>
<reference anchor='PKCS9'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.4648.xml"/>
<title>PKCS #9: Selected Object Classes and Attribute Types Version 2. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
0</title> FC.5652.xml"/>
<author initials="M" surname="Nystrom"></author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="B" surname="Kaliski"></author> FC.7230.xml"/>
<date year='2000' month='November' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.2985.xml"/>
<seriesInfo name='RFC' value='2985' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<format type='TXT' target='http://www.ietf.org/rfc/rfc2985.txt' /> FC.2986.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor='PKCS10'> <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-htt
<front> pbis-bcp56bis.xml"/>
<title>PKCS #10: Certification Request Syntax Specification Version 1.
7</title>
<author initials="M" surname="Nystrom"></author>
<author initials="B" surname="Kaliski"></author>
<date year='2000' month='November' />
</front>
<seriesInfo name='RFC' value='2986' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2986.txt' />
</reference>
<reference anchor='PKIX'> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<front> ence.RFC.4387.xml"/>
<title>Internet X.509 Public Key Infrastructure Certificate and Certif
icate Revocation List (CRL) Profile</title>
<author initials="D" surname="Cooper"></author>
<author initials="S" surname="Santesson"></author>
<author initials="S" surname="Farrell"></author>
<author initials="S" surname="Boeyen"></author>
<author initials="R" surname="Housley"></author>
<author initials="W" surname="Polk"></author>
<date year='2008' month='May' />
</front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5280.txt' />
</reference>
<reference anchor='URI'> <reference anchor="JSCEP" target="https://github.com/jscep/jscep">
<front> <front>
<title>Uniform Resource Identifiers (URI): Generic Syntax</title> <title>A Java implementation of the Simple Certificate Enrolment Pro
<author initials="T" surname="Berners-Lee"></author> tocol</title>
<author initials="R" surname="Fielding"></author> <author />
<author initials="L" surname="Masinter"></author> <date month="January" year="2020"/>
<date year='2005' month='January' /> </front>
</front> <seriesInfo name="commit" value="7410332" />
<seriesInfo name='RFC' value='3986' /> </reference>
<format type='TXT' target='http://www.ietf.org/rfc/rfc3986.txt' />
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7296.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8551.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2634.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5035.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
</references>
</references> </references>
<references title="Informative References">
<reference anchor='BCP56bis'> <section anchor="background" numbered="true" toc="default">
<front> <name>Background Notes</name>
<title>Building Protocols with HTTP</title>
<author initials="M" surname="Nottingham"></author>
<date year='2018' month='November' />
</front>
<!-- <seriesInfo name='RFC' value='XXXX' /> -->
<format type='TXT' target='https://tools.ietf.org/html/draft-ietf-httpbi
s-bcp56bis-08' />
</reference>
<reference anchor='HTTP-certstore'>
<front>
<title>Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP</title>
<author initials="P" surname="Gutmann"></author>
<date year='2006' month='February' />
</front>
<seriesInfo name='RFC' value='4387' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4387.txt' />
</reference>
<reference anchor="JSCEP" target="https://github.com/jscep/jscep">
<front>
<title>A Java implementation of the Simple Certificate Enrolment Proto
col</title>
<author/>
<date/>
</front>
</reference>
<reference anchor='IKEv2'>
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<!-- <author initials="C" surname="Kaufman"></author>
<author initials="P" surname="Hoffman"></author>
<author initials="Y" surname="Nir"></author>
<author initials="P" surname="Eronen"></author>
<author initials="T" surname="Kivinen"></author> -->
<author initials="D" surname="Alighieri"></author>
<!-- <date year='2005' month='December' /> -->
<date year='1300' month='March' />
</front>
<seriesInfo name='RFC' value='7296' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc7296.txt' />
</reference>
<reference anchor='SMIME'>
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3
.2 Message Specification</title>
<author initials="B" surname="Ramsdell"></author>
<author initials="S" surname="Turner"></author>
<date year='2010' month='January' />
</front>
<seriesInfo name='RFC' value='5751' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5751.txt' />
</reference>
<reference anchor='ESS'>
<front>
<title>Enhanced Security Services for S/MIME</title>
<author initials="P" surname="Hoffman"></author>
<date year='1999' month='June' />
</front>
<seriesInfo name='RFC' value='2634' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2634.txt' />
</reference>
<reference anchor='ESSv2'>
<front>
<title>Enhanced Security Services (ESS) Update: Adding CertID Algorith
m Agility</title>
<author initials="J" surname="Schaad"></author>
<date year='2007' month='August' />
</front>
<seriesInfo name='RFC' value='5035' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5035.txt' />
</reference>
<reference anchor='TLS'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization>Mozilla</organization>
</author>
<date year='2018' month='August' />
</front>
<seriesInfo name='RFC' value='8446' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc8446.txt' />
</reference>
</references>
<!-- ======================================================================
-->
<section anchor="background" title="Background Notes">
<t> <t>
This specification has spent over twenty years in the draft stage. Its This specification has spent over twenty years in the draft stage. Its
original goal, provisioning IPsec routers with certificates, has long since original goal, provisioning IPsec routers with certificates, has long since
changed to general device/embedded system/IoT use. To fit this role, extra 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 features were bolted on in a haphazard manner through the addition of a
growing list of appendices and by inserting additional, often conflicting, growing list of appendices and by inserting additional, often conflicting,
paragraphs in various locations in the body text. Since existing features paragraphs in various locations in the body text. Since existing features
were never updated as newer ones were added, the specification accumulated were never updated as newer ones were added, the specification accumulated
large amounts of historical baggage over time. If OpenPGP was described as "a large amounts of historical baggage over time. If OpenPGP was described as "a
museum of 1990s crypto" then the SCEP draft was its graveyard. museum of 1990s crypto", then the SCEP document was its graveyard.
</t> </t>
<t> <t>
About five years ago the specification, which even at that point had seen only 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 sporadic reposts of the existing document, was more or less abandoned by its
original sponsors. Due to its widespread use in large segments of the original sponsors. Due to its widespread use in large segments of the
industry, the specification was rebooted in 2015, cleaning up fifteen years industry, the specification was rebooted in 2015, cleaning up fifteen years'
worth of accumulated cruft, fixing errors, clarifying ambiguities, and worth of accumulated cruft, fixing errors, clarifying ambiguities, and
bringing the algorithms and standards used into the current century (prior to bringing the algorithms and standards used into the current century (prior to
the update, the de-facto lowest-common denominator algorithms used for the update, the de facto lowest-common-denominator algorithms used for
interoperability were the insecure forty-year-old single DES and broken MD5 interoperability were the insecure forty-year-old single DES and broken MD5
hash algorithms). hash algorithms).
</t> </t>
<t> <t>
Note that although the text of the current specification has changed Note that although the text of the current specification has changed
significantly due to the consolidation of features and appendices into the significantly due to the consolidation of features and appendices into the
main document, the protocol that it describes is identical on the wire to the main document, the protocol that it describes is identical on the wire to the
original (with the unavoidable exception of the switch from single DES and MD5 original (with the unavoidable exception of the switch from single DES and MD5
skipping to change at line 2968 skipping to change at line 2622
indicator in GetCACaps and the failInfoText attribute, are both optional indicator in GetCACaps and the failInfoText attribute, are both optional
values and would be ignored by older implementations that don't support them, 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. or can be omitted from messages if they are found to cause problems.
</t> </t>
<t> <t>
Other changes include: Other changes include:
</t> </t>
<t> <ul>
<li>Resolved contradictions in the text -- for example, a requirement
<list style="symbols"> given as a <bcp14>MUST</bcp14> in one paragraph and a
<bcp14>SHOULD</bcp14> in the next, a <bcp14>MUST NOT</bcp14>
<t>Resolved contradictions in the text, for example a requirement in one paragraph and a <bcp14>MAY</bcp14> a few paragraphs later, a
given as a MUST in one paragraph and a SHOULD in the next, a MUST <bcp14>SHOULD NOT</bcp14> contradicted later by a <bcp14>MAY</bcp14>, and
NOT so on.</li>
in one paragraph and a MAY a few paragraphs later, a SHOULD NOT <li>Merged several later fragmentary addenda placed in appendices (for
contradicted later by a MAY, and so on.</t> example, the handling of certificate renewal) with the body of the
text.</li>
<t>Merged several later fragmentary addenda placed in appendices <li>Merged the "SCEP Transactions" and "SCEP Transport" sections, since
(for the
example the handling of certificate renewal) with the body of the
text.</t>
<t>Merged the SCEP Transactions and SCEP Transport sections, sinc
e the
latter mostly duplicated (with occasional inconsistencies) the latter mostly duplicated (with occasional inconsistencies) the
former.</t> former.</li>
<li>Updated the algorithms to ones dating from at least this
<t>Updated the algorithms to ones dating from at least this century.</li>
century.</t> <li>Did the same for normative references to other standards.</li>
<li>Updated the text to use consistent terminology for the client and
<t>Did the same for normative references to other standards.</t>
<t>Updated the text to use consistent terminology for the client
and
CA rather than a mixture of client, requester, requesting system, end CA rather than a mixture of client, requester, requesting system, end
entity, server, certificate authority, certification authority, a nd entity, server, certificate authority, certification authority, a nd
CA.</t> CA.</li>
<li>Corrected incorrect references to other standards, e.g.,
<t>Corrected incorrect references to other standards, e.g. IssuerAndSerial -&gt; IssuerAndSerialNumber.</li>
IssuerAndSerial -> IssuerAndSerialNumber.</t> <li>Corrected errors such as a statement that when both signature and
<t>Corrected errors such as a statement that when both signature
and
encryption certificates existed, the signature certificate was us ed encryption certificates existed, the signature certificate was us ed
for encryption.</t> for encryption.</li>
<li>Condensed redundant discussions of the same topic spread across
<t>Condensed redundant discussions of the same topic spread acros multiple sections into a single location. For example, the descr
s iption
multiple sections into a single location. For example the descri
ption
of intermediate CA handling previously existed in three different of intermediate CA handling previously existed in three different
locations, with slightly different reqirements in each one.</t> locations, with slightly different requirements in each one.</li>
<li>Added a description of how pkiMessages were processed, which was
<t>Added a description of how pkiMessages were processed, which w
as
never made explicit in the original specification. This led to never made explicit in the original specification. This led to
creative interpretations that had security problems but were empl oyed creative interpretations that had security problems but were empl oyed
anyway due to the lack of specific guidance on what to do.</t> anyway due to the lack of specific guidance on what to do.</li>
<li>Relaxed some requirements that didn't serve any obvious purpose and
<t>Relaxed some requirements that didn't serve any obvious purpos that major implementations didn't seem to be enforcing. For exam
e and ple,
that major implementations didn't seem to be enforcing. For exam
ple
the requirement that the self-signed certificate used with a requ est the requirement that the self-signed certificate used with a requ est
MUST contain a subject name that matched the one in the PKCS #10 <bcp14>MUST</bcp14> contain a subject name that matched the one i
request was relaxed to a SHOULD because a number of implementatio n the PKCS #10
ns request was relaxed to a <bcp14>SHOULD</bcp14>, because a number
of implementations
either ignored the issue entirely or at worst performed some mino r either ignored the issue entirely or at worst performed some mino r
action like creating a log entry after which they continued action like creating a log entry, after which they continued
anyway.</t> anyway.</li>
<li>Removed discussion of the transactionID from the security
<t>Removed discussion of the transactionID from the security
considerations, since the instructions there were directly considerations, since the instructions there were directly
contradicted by the discussion of the use of the transactionID in contradicted by the discussion of the use of the transactionID in
<xref target="state-trans"/>.</t> <xref target="state-trans" format="default"/>.</li>
<li>Added a requirement that the signed message include the signing
<t>Added a requirement that the signed message include the signin
g
certificate(s) in the signedData certificates field. This was certificate(s) in the signedData certificates field. This was
implicit in the original specification (without it, the message implicit in the original specification (without it, the message
couldn't be verified by the CA) and was handled by the fact that most 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 explicitl y PKCS #7/CMS libraries do this by default, but was never explicitl y
mentioned.</t> mentioned.</li>
<li>Clarified sections that were unclear or even made no sense -- for
<t>Clarified sections that were unclear or even made no sense, fo example, the requirement for a "hash on the public key" [sic] enc
r oded
example the requirement for a "hash on the public key" [sic] enco as a PrintableString.</li>
ded <li>Renamed "RA certificates" to "intermediate CA certificates". The
as a PrintableString.</t>
<t>Renamed "RA certificates" to "intermediate CA certificates".
The
original document at some point added mention of RA certificates original document at some point added mention of RA certificates
without specifying how the client was to determine that an RA was in without specifying how the client was to determine that an RA was in
use, how the RA operations were identified in the protocol, or ho w it use, how the RA operations were identified in the protocol, or ho w it
was used. It's unclear whether what was meant was a true RA or m erely was used. It's unclear whether what was meant was a true RA or m erely
an intermediate CA, as opposed to the default practice of having an intermediate CA, as opposed to the default practice of having
certificates issued directly from a single root CA certificate. This certificates issued directly from a single root CA certificate. This
update uses the term "intermediate CA certificates", since this s eems update uses the term "intermediate CA certificates", since this s eems
to have been the original intent of the text.</t> to have been the original intent of the text.</li>
<li>Redid the PKIMessage diagram to match what was specified in CMS;
<t>Redid the PKIMessage diagram to match what was specified in CM
S,
the original diagram omitted a number of fields and nested data the original diagram omitted a number of fields and nested data
structures which meant that the diagram didn't match either the t structures, which meant that the diagram didn't match either the
ext text
or the CMS specification.</t> or the CMS specification.</li>
<li>Removed the requirement for a CertPoll to contain a recipientNonce,
<t>Removed the requirement for a CertPoll to contain a recipientN
once,
since CertPoll is a client message and will never be sent in resp onse since CertPoll is a client message and will never be sent in resp onse
to a message containing a senderNonce. See also the note in to a message containing a senderNonce. See also the note in
<xref target="CertRep"/>.</t> <xref target="CertRep" format="default"/>.</li>
<li>Clarified certificate renewal. This represents a capability that
<t>Clarified certificate renewal. This represents a capability t was bolted onto the original protocol with (at best) vaguely defi
hat ned
was bolted onto the original protocol with (at best) vaguely-defi
ned
semantics, including a requirement by the CA to guess whether a semantics, including a requirement by the CA to guess whether a
particular request was a renewal or not. In response to develope r particular request was a renewal or not. In response to develope r
feedback that they either avoided renewal entirely because of thi s feedback that they either avoided renewal entirely because of thi s
uncertainty or hardcoded in particular behaviour on a per-CA basi uncertainty or hard-coded in particular behaviour on a per-CA bas
s, is,
this specification explicitly identifies renewal requests as such this specification explicitly identifies renewal requests as such
, and and
provides proper semantics for them.</t> provides proper semantics for them.</li>
<li>Corrected the requirement that "undefined message types are treated
<t>Corrected the requirement that "undefined message types are tr as an error", since this negates the effect of GetCACaps, which i
eated s used
as an error" since this negates the effect of GetCACaps, which is to define new message types. In particular, operations such as
used
to define new message types. In particular operations such as
GetCACaps "Renewal" would be impossible if enforced as written, GetCACaps "Renewal" would be impossible if enforced as written,
because the Renewal operation was an undefined message type at th e because the Renewal operation was an undefined message type at th e
time.</t> time.</li>
<li>In line with the above, added IANA registries for several entries
<t>In line with the above, added IANA registries for several entr that had previously been defined in an ad hoc manner in different
ies locations in the text.</li>
that had previously been defined in an ad-hoc manner in different <li>Added the "SCEPStandard" keyword to GetCACaps to indicate that the
locations in the text.</t>
<t>Added the "SCEPStandard" keyword to GetCACaps to indicate that
the
CA complies with the final version of the SCEP standard, since th e CA complies with the final version of the SCEP standard, since th e
definition of what constitutes SCEP standards compliance has chan ged definition of what constitutes SCEP standards compliance has chan ged
significantly over the years.</t> significantly over the years.</li>
<li>Added the optional failInfoText attribute to deal with the fact
<t>Added the optional failInfoText attribute to deal with the fac
t
that failInfo was incapable of adequately communicating to client s why that failInfo was incapable of adequately communicating to client s why
a certificate request operation had been rejected.</t> a certificate request operation had been rejected.</li>
<li>Removed the discussion in the security considerations of revocation
<t>Removed the discussion in the security considerations of revoc
ation
issues, since SCEP doesn't support revocation as part of the issues, since SCEP doesn't support revocation as part of the
protocol.</t> protocol.</li>
<li>Clarified the use of nonces, which if applied as originally
<t>Clarified the use of nonces, which if applied as originally
specified would have made the use of polling in the presence of a lost specified would have made the use of polling in the presence of a lost
message impossible.</t> message impossible.</li>
<li>Removed the discussion of generating a given transactionID by
<t>Removed the discussion of generating a given transactionID by
hashing the public key, since this implied that there was some sp ecial hashing the public key, since this implied that there was some sp ecial
significance in the value generated this way. Since it was neith er a significance in the value generated this way. Since it was neith er a
MUST nor a MAY, it was unsound to imply that servers could rely o <bcp14>MUST</bcp14> nor a <bcp14>MAY</bcp14>, it was unsound
n the to imply that servers could rely on the
value being generated a certain way. In addition it wouldn't wor value being generated a certain way. In addition, it wouldn't wo
k if rk if
multiple transactions as discussed in <xref target="poll-resp"/> multiple transactions as discussed in <xref target="poll-resp"
were format="default"/> were
initiated, since the deterministic generation via hashing would l ead initiated, since the deterministic generation via hashing would l ead
to duplicate transactionIDs.</t> to duplicate transactionIDs.</li>
<li>Added examples of SCEP messages to give implementers something to
<t>Added examples of SCEP messages to give implementers something aim for.</li>
to </ul>
aim for.</t> </section>
</list> <section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The editor would like to thank all of the previous editors, authors, and
contributors for their work maintaining the
document over the years: <contact fullname="Cheryl Madson"/>, <contact
fullname="Xiaoyi Liu"/>, <contact fullname="David McGrew"/>, <contact
fullname="David Cooper"/>, <contact fullname="Andy Nourse"/>, <contact fullname=
"Max
Pritikin"/>, <contact fullname="Jan Vilhuber"/>, and others. The IETF reviewers
provided
much useful feedback that
helped improve the document, and in particular spotted a number of things that
were present in SCEP through established practice rather than by being
explicitly described in the text. Numerous other people have contributed
during the long life cycle of the document, and all deserve thanks. In addition
,
several PKCS #7 / CMS libraries contributed to interoperability by doing the
right thing despite what earlier SCEP documents required.
</t>
<t>
The authors of earlier draft versions of this document would like to thank
<contact fullname="Peter William"/> of ValiCert, Inc. (formerly of VeriSign,
Inc.), <contact fullname="Alex Deacon"/> of
VeriSign, Inc., and <contact fullname="Christopher Welles"/> of IRE, Inc. for th
eir contributions to
early versions of this protocol and this document.
</t>
</section>
</t>
</section>
<!-- ======================================================================
-->
</back> </back>
</rfc> </rfc>
 End of changes. 452 change blocks. 
2314 lines changed or deleted 1974 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/