<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc tocdepth='5'?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >

<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="info" consensus="true" ipr="pre5378Trust200902" docName="draft-gutmann-scep-16">
     docName="draft-gutmann-scep-16" number="8894" obsoletes="" updates=""
     xml:lang="en" tocInclude="true" tocDepth="5" symRefs="true"
     sortRefs="true" version="3">

  <!-- ======================================================================== xml2rfc v2v3 conversion 2.42.0 -->

  <front>
    <title abbrev="SCEP">Simple Certificate Enrolment Protocol</title>
    <seriesInfo name="RFC" value="8894" />
    <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
      <organization abbrev="University of Auckland">University of Auckland</organization>
      <address>
        <postal>
          <street>Department of Computer Science</street>
          <city>Auckland</city>
          <country>New Zealand</country>
        </postal>
        <email>pgut001@cs.auckland.ac.nz</email>
      </address>
    </author>
    <date year="2020"/> month="September" year="2020" />
    <area>Security Area</area>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>

This document specifies the Simple Certificate Enrolment Protocol (SCEP), a
PKI protocol that leverages existing technology by using CMS (formerly Cryptographic Message
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
and server implementations, as well as being relied upon by numerous other
industry standards that work with certificates.

      </t>
    </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>
  <!-- ======================================================================== -->

  <middle>

    <!-- ====================================================================== -->

    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>

X.509 certificates serve as the basis for several standardised security
protocols such as <xref target="TLS">TLS</xref>, target="RFC8446" format="default">TLS</xref>, <xref target="SMIME">
S/MIME</xref>,
target="RFC8551" format="default">S/MIME</xref>, and <xref target="IKEv2">IKE/IPsec</xref>. target="RFC7296"
format="default">IKE/IPsec</xref>.  When an X.509
certificate is issued issued, there typically is a need for a certificate management
protocol to enable a PKI client to request or renew a certificate from a
Certificate Authority (CA).  This specification defines a protocol, the Simple
Certificate Enrolment Protocol (SCEP), for certificate management and
certificate and CRL queries.

      </t>
      <t>

The SCEP protocol supports the following general operations:

      </t>
      <t>

      <list style="symbols">

		<t>CA
      <ul spacing="compact">
        <li>CA public key distribution.</t>

		<t>Certificate distribution</li>
        <li>Certificate enrolment and issue.</t>

		<t>Certificate renewal.</t>

		<t>Certificate query.</t>

		<t>CRL query.</t>

      </list>

      </t> issue</li>
        <li>Certificate renewal</li>
        <li>Certificate query</li>
        <li>CRL query</li>
      </ul>
      <t>

SCEP makes extensive use of <xref target="CMS">CMS</xref> target="RFC5652" format="default">CMS</xref>
and <xref
target="PKCS10">PKCS target="RFC2986" format="default">PKCS #10</xref>.
      </t>

      <section anchor="mustshouldmay" title="Conventions numbered="true" toc="default">
        <name>Conventions Used in This Document"> Document</name>
        <t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
		  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
		  "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	  "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	  NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	  "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	  "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
	  are to be interpreted as
	  described in BCP&nbsp;14 <xref target="RFC2119"/> and <xref target="RFC8174"/>
	  when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

        <t>This document uses the Augmented Backus-Naur Form (ABNF) notation
        as specified in <xref target="ABNF"/> target="RFC5234" format="default"/> for defining formal syntax of
	commands.  Non-terminals not defined in <xref target="ABNF"/> target="RFC5234" format="default"/> are
	defined in <xref target="HTTP-GET-POST"/>.</t> target="HTTP-GET-POST" format="default"/>.</t>
      </section>
    </section>
    <!-- ====================================================================== -->

    <section anchor="overview" title="SCEP Overview"> numbered="true" toc="default">
      <name>SCEP Overview</name>
      <t>

This section provides an overview of the functionality of SCEP.

      </t>
      <section anchor="overview-entities" title="SCEP Entities"> numbered="true" toc="default">
        <name>SCEP Entities</name>
        <t>

The entity types defined in SCEP are a client requesting a certificate and a
Certificate Authority (CA) that issues the certificate.  These are described
in the following sections.

        </t>
        <section anchor="overview-client" title="Client"> numbered="true" toc="default">
          <name>Client</name>
          <t>

A client MUST <bcp14>MUST</bcp14> have the following information locally configured:

          </t>
          <t>

          <list style="numbers">

			<t>The
          <ol type="1">
            <li>The CA's fully qualified domain name or IP address.</t>

			<t>Any address.</li>
            <li>Any identification and/or authorisation information required by
			the CA before a certificate will be issued, as described in
			<xref target="PKCSReq"/>.</t>

			<t>The target="PKCSReq" format="default"/>.</li>
            <li>The identifying information that is used for authentication of
			the CA in <xref target="GetCACert-resp"/>, target="GetCACert-resp" format="default"/>, typically a certificate
			fingerprint.</t>

          </list>

          </t>
			fingerprint.</li>
          </ol>
        </section>
        <section anchor="overview-ca" title="Certificate Authority"> numbered="true" toc="default">
          <name>Certificate Authority</name>
          <t>
A SCEP CA is the entity that signs client certificates.  A CA may enforce
policies and apply them to certificate requests, and it may reject a request for
any reason.
          </t>

          <t>
Since the client is expected to perform signature verification and optionally
encryption using the CA certificate, the keyUsage extension in the CA
certificate MUST <bcp14>MUST</bcp14> indicate that it is valid for digitalSignature and
keyEncipherment (if the key is to be used for en/decryption) alongside the
usual CA usages of keyCertSign and/or cRLSign.
          </t>
        </section>
      </section>
      <section anchor="overview-cert-dist" title="CA numbered="true" toc="default">
        <name>CA Certificate Distribution"> Distribution</name>
        <t>
If the CA certificate(s) have not previously been acquired by the client
through some other means, the client MUST <bcp14>MUST</bcp14> retrieve them before any PKI
operation (<xref target="message-obj"/>) 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
secured using CMS, and the CA certificate request and response data is instead
transferred in the clear.
        </t>
        <t>
If an intermediate CA is in use, a certificates-only CMS Signed-Data SignedData message
with a certificate chain consisting of all CA certificates is returned.
Otherwise
Otherwise, the CA certificate itself is returned.
        </t>
        <t>
The CA certificate MAY <bcp14>MAY</bcp14> be provided out-of-band out of band to the client.  Alternatively,
the CA certificate fingerprint MAY <bcp14>MAY</bcp14> be used to authenticate a CA Certificate certificate
distributed by the GetCACert response (<xref target="GetCACert"/>) target="GetCACert" format="default"/>) or via
<xref target="HTTP-certstore">HTTP target="RFC4387" format="default">HTTP certificate-store access</xref>.  The
fingerprint is created by calculating a SHA-256 hash over the whole CA
certificate (for
certificate. (For legacy reasons, a SHA-1 hash may be used by some
implementations).
implementations.)

        </t>
        <t>

After the client gets the CA certificate, it SHOULD <bcp14>SHOULD</bcp14> authenticate it in some
manner unless this is deemed unnecessary, for example example, because the device is
being provisioned inside a trusted environment.  For example it example, the client could compare
its
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
locally-stored
locally stored copy of the certificate.

        </t>
        <t>

Intermediate CA certificates, if any, are signed by a higher-level CA CA, so there
is no need to authenticate them against the out-of-band data.  Since
intermediate CA certificates are rolled over more frequently than long-lived
top-level CA certificates, clients MUST <bcp14>MUST</bcp14> verify intermediate-level CA
certificates before use during protocol exchanges in case the intermediate CA
certificate has expired or otherwise been invalidated.

        </t>
        <t>

When a CA certificate expires, certificates that have been signed by it may no
longer be regarded as valid.  CA key rollover provides a mechanism by which
the CA can distribute a new CA certificate which is that will be valid in the future once
the current certificate has expired.  This is done via the GetNextCACert
message (section <xref target="get-next-CA"/>). (<xref target="get-next-CA" format="default"/>).

        </t>
      </section>
      <section anchor="overview-req-auth" title="Client authentication"> numbered="true" toc="default">
        <name>Client Authentication</name>
        <t>

As with every protocol that uses public-key cryptography, the association
between the public keys used in the protocol and the identities with which
they are associated must be authenticated in a cryptographically secure
manner.  Communications between the client and the CA are secured using SCEP
Secure Message Objects as explained in <xref target="message-obj"/>, target="message-obj" format="default"/>, which
specifies how CMS is used to encrypt and sign the data.  In order to perform
the signing operation operation, the client uses an appropriate local certificate:

        </t>
        <t>

        <list style="numbers">

		  <t>If
        <ol type="1">
          <li>If the client does not have an appropriate existing certificate certificate,
		  then a locally generated self-signed certificate MUST <bcp14>MUST</bcp14> be used.  The
		  keyUsage extension in the certificate MUST <bcp14>MUST</bcp14> indicate that it is valid
		  for digitalSignature and keyEncipherment (if available).  The
		  self-signed certificate SHOULD <bcp14>SHOULD</bcp14> use the same subject name and key as
		  in the PKCS #10 request.  In this case case, the messageType is PKCSReq
		  (see <xref target="messageType"/>).</t>

		  <t>If target="messageType" format="default"/>).</li>
          <li>If the client already has a certificate issued by the SCEP CA CA, and
		  the CA supports renewal (see <xref target="overview-cert-enrol"/>), target="overview-cert-enrol" format="default"/>),
		  that certificate SHOULD <bcp14>SHOULD</bcp14> be used. In this case case, the messageType is
		  RenewalReq (see <xref target="messageType"/>).</t>

		  <t>Alternatively, target="messageType" format="default"/>).</li>
          <li>Alternatively, if the client has no certificate issued by the
		  SCEP CA but has credentials from an alternate CA CA, then the
		  certificate issued by the alternate CA MAY <bcp14>MAY</bcp14> be used in a renewal
		  request as described above.  The SCEP CA's policy will determine
		  whether the request can be accepted or not.</t>

        </list>

        </t> not.</li>
        </ol>
        <t>
Note that although the above text describes several different types of
operations, for historical reasons reasons, most implementations always apply the first
one
one, even if an existing certificate already exists.  For this reason reason, support
for the first case is mandatory while support for the latter ones are optional
(see <xref target="MTI"/>). target="MTI" format="default"/>).
        </t>
        <t>
During the certificate enrolment certificate-enrolment process, the client MUST <bcp14>MUST</bcp14> use
the selected certificate's key when signing the CMS envelope (see <xref
target="message-obj"/>).
target="message-obj" format="default"/>).  This certificate will be either the
self-signed one matching the PKCS #10 request or the CA-issued one used to
authorise a renewal, and MUST it <bcp14>MUST</bcp14> be included in the signedData
certificates field (possibly as part of a full certificate chain).  If the key
being certified allows
encryption encryption, then the CA's CertResp will use the same
certificate's public key when encrypting the response.
        </t>
        <t>
Note that that, in the case of renewal operations operations, this means that the request will
be signed and authenticated with the key in the previously-issued previously issued certificate
rather than the key in the PKCS #10 request, and the response may similarly be
returned encrypted with the key in the previously-issued previously issued certificate.  This
has security implications, implications; see <xref target="security-no-pop"/>. target="security-no-pop" format="default"/>.
        </t>
      </section>

      <section anchor="overview-enrol-auth" title="Enrolment authorisation"> numbered="true" toc="default">
        <name>Enrolment Authorisation</name>
        <t>

<xref target="PKCS10">PKCS target="RFC2986" format="default">PKCS #10</xref> specifies a <xref target="PKCS9">PKCS target="RFC2985" format="default">PKCS
#9</xref> challengePassword attribute to be sent as part of the enrolment
request.  When utilizing utilising the challengePassword, the CA distributes a shared
secret to the client client, which will be used to authenticate the request from the
the
client.  It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the challengePassword be a
one-time
authenticator value to limit the ability of an attacker who can capture the
authenticator from the client or CA to re-use and reuse it to request further
certificates.

        </t>
        <t>

Inclusion of the challengePassword by the SCEP client is RECOMMENDED, however
<bcp14>RECOMMENDED</bcp14>; however,
its omission allows for unauthenticated authorisation of enrolment requests
(which may, however, require manual approval of each certificate issue if
other security measures to control issue aren't in place, place; see below).
Inclusion is OPTIONAL <bcp14>OPTIONAL</bcp14> for renewal requests that are authenticated by being
signed with an existing certificate.  The CMS envelope protects the privacy of
the challengePassword.

        </t>
        <t>

A client that is performing certificate renewal as per <xref
target="overview-cert-enrol"/> SHOULD target="overview-cert-enrol" format="default"/> <bcp14>SHOULD</bcp14> omit the challengePassword but MAY <bcp14>MAY</bcp14> send
the originally distributed shared secret in the challengePassword attribute.
The SCEP CA MAY use <bcp14>MAY</bcp14> authenticate the request using the
challengePassword in addition to the previously issued certificate that signs
the request to authenticate the request. The SCEP CA
MUST NOT <bcp14>MUST NOT</bcp14> attempt to authenticate a
client based on a self-signed certificate unless it has been verified through
out-of-band means such as a certificate fingerprint.
        </t>
        <t>

To perform the authorisation in manual mode mode, the client's request is placed in
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
hasn't been previously authenticated by the CA and/or a challengePassword is
not available.  The SCEP CA MAY <bcp14>MAY</bcp14> either reject unauthorised requests or mark
them for manual authorisation according to CA policy.

        </t>
      </section>
      <section anchor="overview-cert-enrol" title="Certificate Enrolment/Renewal"> numbered="true" toc="default">
        <name>Certificate Enrolment/Renewal</name>
        <t>
A client starts an enrolment transaction (<xref target="PKCSReq"/>) target="PKCSReq" format="default"/>) by creating a
certificate request using PKCS #10 and sends it the request to the CA enveloped
using CMS (<xref target="message-obj"/>). target="message-obj" format="default"/>).
        </t>
        <t>

If the CA supports certificate renewal and if the CA policy permits permits, then a new
certificate with new validity dates can be issued issued, even though the old one is
still valid.  To renew an existing certificate, the client uses the RenewalReq
message (see <xref target="pkiMessage-types"/>) target="pkiMessage-types" format="default"/>) and signs it with the existing
client certificate.  The client SHOULD <bcp14>SHOULD</bcp14> use a new keypair when requesting a new
certificate,
certificate but MAY <bcp14>MAY</bcp14> request a new certificate using the old keypair.

        </t>
        <t>

If the CA returns a CertRep message (<xref target="CertRep"/>) target="CertRep" format="default"/>) with status set
to PENDING, the client enters into polling mode by periodically sending a
CertPoll message (<xref target="CertPoll"/>) target="CertPoll" format="default"/>) to the CA until the CA operator
completes the manual authentication (approving or denying the request). The
frequency of the polling operation is a CA/client configuration issue, issue and may
range from seconds or minutes when the issue process is automatic but not
instantaneous, through to hours or days if the certificate issue certificate-issue operation
requires manual approval.

        </t>
        <t>

If polling mode is being used used, then the client will send a single
PKCSReq/RenewalReq message (<xref target="PKCSReq"/>), target="PKCSReq" format="default"/>), followed by 0 or more
CertPoll messages (<xref target="CertPoll"/>). target="CertPoll" format="default"/>).  The CA will will, in return return, send 0
or more CertRep messages (<xref target="CertRep"/>) target="CertRep" format="default"/>) with status set to PENDING
in response to CertPolls, followed by a single CertRep message (<xref
target="CertRep"/>)
target="CertRep" format="default"/>) with status set to either SUCCESS or
FAILURE.

        </t>
        <section anchor="overview-client-state" title="Client numbered="true" toc="default">
          <name>Client State Transitions"> Transitions</name>
          <t>

The client state transitions during the SCEP process are indicated in <xref
target="state-diagram"/>. target="state-diagram" format="default"/>.

          </t>
          <figure anchor="state-diagram" title="State anchor="state-diagram">
            <name>State Transition Diagram">
			<artwork><![CDATA[ Diagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                                CertPoll
                              +-----<----+
                              |          |
                              |          | CertRep(PENDING)
                              |          |
[CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] ---------> --------> [CERT-ISSUED]
      ^            PKCSReq    |           CertRep(SUCCESS)
      |          RenewalReq   |
      |                       |
      +-----------------------+
      CertRep(FAILURE) or
      Max-time/max-polls exceeded
			]]></artwork>
          </figure>
          <t>

The certificate issue certificate-issue process starts at state CERT-NONEXISTENT.  Sending a
PKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING.

          </t>
          <t>

If the CA returns a CertRep message with pkiStatus set to SUCCESS SUCCESS, then the
state changes to CERT-ISSUED.

          </t>
          <t>

If the CA returns a CertRep message with pkiStatus set to FAILURE or there is
no response response, then the state reverts back to CERT-NONEXISTENT.

          </t>
          <t>

If the CA returns a CertRep message with pkiStatus set to PENDING PENDING, then the
client will keep polling by sending a CertPoll message until either a CertRep
message with status set to SUCCESS or FAILURE is received or received, a timeout occurs occurs,
or the maximum number of polls has been exceeded.

          </t>
		  <figure>
		  	<preamble>A
          <t><xref target="automatic" /> shows a successful transaction in
	  automatic mode:</preamble>
			<artwork><![CDATA[ mode</t>
<figure anchor="automatic">
<name>Automatic Mode</name>
          <artwork type="" align="left" alt=""><![CDATA[
    CLIENT                              CA SERVER

PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = SUCCESS
                                  Certificate attached
                                  <------------------------------
Receive issued certificate.
			]]></artwork>
</figure>

		  <figure>
		  	<preamble>A

          <t><xref target="manual"/> shows a successful transaction in manual mode:</preamble>
			<artwork><![CDATA[
	  mode:</t>
<figure anchor="manual">
<name>Manual Mode</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    CLIENT                              CA SERVER

PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = PENDING
                                  <------------------------------
CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = PENDING
                                  <------------------------------
................ <Manual identity authentication> ...............

CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = SUCCESS
                                  Certificate attached
                                  <------------------------------
Receive issued certificate.
			]]></artwork>
</figure>
        </section>
      </section>
      <section anchor="overview-cert-access" title="Certificate Access"> numbered="true" toc="default">
        <name>Certificate Access</name>
        <t>

A certificate query message is defined for clients to retrieve a copy of their
own certificate from the CA.  It allows clients that do not store their
certificates locally to obtain a copy when needed.  This functionality is not
intended to provide a general purpose certificate access general-purpose certificate-access service, which may be
instead be
achieved instead via <xref target="HTTP-certstore">HTTP target="RFC4387" format="default">HTTP certificate-store
access</xref> or LDAP. Lightweight Directory Access Protocol (LDAP).

        </t>
        <t>

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
has saved the issuer name and the serial number of the issued certificate from
the previous enrolment transaction.  The transaction to retrieve a certificate
consists of one GetCert (<xref target="GetCertCRL"/>) target="GetCertCRL" format="default"/>) message and one CertRep
(<xref target="CertRep"/>) target="CertRep" format="default"/>) message, as shown below. in <xref target="retrieve"/>.

        </t>
		<figure>
		  <artwork><![CDATA[
<figure anchor="retrieve">
<name>Retrieving a Certificate</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   CLIENT                               CA SERVER

GetCert: PKI certificate query message
-------------------------------> CertRep: pkiStatus = SUCCESS
                                 Certificate attached
                                 <-----------------------------
Receive the certificate.
		  ]]></artwork>
</figure>
      </section>
      <section anchor="overview-CRL-access" title="CRL Access"> numbered="true" toc="default">
        <name>CRL Access</name>
        <t>

SCEP clients MAY <bcp14>MAY</bcp14> request a CRL via one of three methods:

        </t>
        <t>

        <list style="numbers">

		  <t>If
        <ol type="1">
          <li>If the CA supports the <xref target="PKIX">CRL target="RFC5280" format="default">CRL Distribution
		  Points (CRLDPs) extension</xref> in issued certificates, then the
		  CRL MAY <bcp14>MAY</bcp14> be retrieved via the mechanism specified in the CRDLP.</t>

		  <t>If CRLDP.</li>
          <li>If the CA supports <xref target="HTTP-certstore">HTTP target="RFC4387" format="default">HTTP
		  certificate-store access</xref>, then the CRL MAY <bcp14>MAY</bcp14> be retrieved via
		  the <xref target="PKIX">AuthorityInfoAcces</xref> target="RFC5280" format="default">AuthorityInfoAcces</xref> location specified
		  in the certificate.</t>

		  <t>Only certificate.</li>
          <li>Only if the CA does not support CRDLPs CRLDPs or HTTP access should a
		  CRL query be composed by creating a GetCRL message consisting of the
		  issuer name and serial number from the certificate whose revocation
		  status is being queried.</t>

		</list>

		</t> queried.</li>
        </ol>
        <t>

The message is sent to the SCEP CA in the same way as the other SCEP requests.
The transaction to retrieve a CRL consists of one GetCRL PKI message and one
CertRep PKI message, which contains only the CRL (no certificates) in a
degenerate certificates-only CMS Signed-Data SignedData message
(<xref target="certs-only"/>), target="certs-only" format="default"/>), as shown below. in <xref target="retrieve-CRL"/>.

        </t>
		<figure>
		  <artwork><![CDATA[
<figure anchor="retrieve-CRL">
<name>Retrieving a CRL</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
       CLIENT                           CA SERVER

   GetCRL: PKI CRL query message
---------------------------------->
                                  CertRep: CRL attached
                                  <-----------------------------
Receive the CRL
		  ]]></artwork>
</figure>
      </section>
      <section anchor="overview-cert-rev" title="Certificate Revocation"> numbered="true" toc="default">
        <name>Certificate Revocation</name>
        <t>

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 non-SCEP-defined mechanism.
        </t>
      </section>
      <section anchor="MTI" title="Mandatory-to-Implement Functionality"> numbered="true" toc="default">
        <name>Mandatory-to-Implement Functionality</name>
        <t>

At a minimum, all SCEP implementations compliant with this specification MUST <bcp14>MUST</bcp14>
support <xref target="CA-caps-HTTP">GetCACaps</xref>, target="CA-caps-HTTP" format="default">GetCACaps</xref>,
<xref target="GetCACert">GetCACert</xref>, target="GetCACert" format="default">GetCACert</xref>,
<xref target="PKCSReq">PKCSReq</xref> target="PKCSReq" format="default">PKCSReq</xref> (and its associated response messages),
communication of binary data via <xref target="HTTP-GET-POST">HTTP target="HTTP-GET-POST" format="default">HTTP
POST</xref>, and the <xref target="AES">AES128-CBC</xref> target="AES" format="default">AES128-CBC</xref> and
<xref target="SHA2">SHA-256</xref> target="SHA2" format="default">SHA-256</xref> algorithms to secure
<xref target="pkiMessage">pkiMessages</xref>. target="pkiMessage" format="default">pkiMessages</xref>.

        </t>
        <t>

For historical reasons reasons, implementations MAY <bcp14>MAY</bcp14> support communications of binary
data via <xref target="HTTP-GET-POST">HTTP target="HTTP-GET-POST" format="default">HTTP GET</xref>, and the triple DES-CBC
and SHA-1 algorithms to secure <xref target="pkiMessage">pkiMessages</xref>. target="pkiMessage" format="default">pkiMessages</xref>.
Implementations MUST NOT <bcp14>MUST NOT</bcp14> support the obsolete and/or insecure single DES and
MD5 algorithms used in earlier versions of this specification, since the
unsecured nature of GetCACaps means that an in-path attacker can trivially
roll back the encryption used to these insecure algorithms, algorithms; see <xref
target="security-getcacaps"/>.
target="security-getcacaps" format="default"/>.

        </t>
      </section>
    </section>
    <!-- ====================================================================== -->

    <section anchor="message-obj" title="SCEP numbered="true" toc="default">
      <name>SCEP Secure Message Objects"> Objects</name>
      <t>

CMS is a general enveloping mechanism that enables both signed and encrypted
transmission of arbitrary data.  SCEP messages that require confidentiality
use two layers of CMS, as shown using ASN.1-like pseudocode in
<xref target="cms-layering"/>. target="cms-layering" format="default"/>.  By applying both enveloping and signing
transformations, the SCEP message is protected both for the integrity of its
end-to-end transaction information and the confidentiality of its information
portion.

      </t>
      <figure anchor="cms-layering" title="CMS Layering">
		<artwork><![CDATA[ anchor="cms-layering">
        <name>CMS Layering</name>
<sourcecode type="pseudocode">
pkiMessage {
  contentType = signedData { pkcs-7 2 },
  content {
    digestAlgorithms,
    encapsulatedContentInfo {
      eContentType = data { pkcs-7 1 },
      eContent {           -- pkcsPKIEnvelope, optional
        contentType = envelopedData { pkcs-7 3 },
        content {
          recipientInfo,
          encryptedContentInfo {
            contentType = data { pkcs-7 1 },
            contentEncrAlgorithm,
            encryptedContent {
              messageData  -- Typically PKCS #10 request
              }
            }
          }
        }
      },
    certificates,          -- Optional
    crls,                  -- Optional
    signerInfo {
      signedAttrs {
        transactionID,
        messageType,
        pkiStatus,
        failInfo,          -- Optional
        senderNonce / recipientNonce,
        },
      signature
      }
    }
  }

		]]></artwork>
</sourcecode>
      </figure>
      <t>

When a particular SCEP message carries data, this data is carried in the
messageData.  CertRep messages will lack any signed content and consist only
of a pkcsPKIEnvelope (<xref target="pkcsPKIEnvelope"/>). target="pkcsPKIEnvelope" format="default"/>).

      </t>
      <t>

The remainder of this document will refer only to 'messageData', "messageData", but it is
understood to always be encapsulated in the pkcsPKIEnvelope (<xref
target="pkcsPKIEnvelope"/>). target="pkcsPKIEnvelope" format="default"/>).  The format of the data in the messageData is
defined by the messageType attribute (see <xref target="pkiMessage"/>) target="pkiMessage" format="default"/>) of the
Signed-Data.
SignedData.  If there is no messageData to be transmitted, the entire
pkcsPKIEnvelope MUST <bcp14>MUST</bcp14> be omitted.

      </t>
      <t>

Samples of SCEP messages are available through the
<xref target="JSCEP">JSCEP target="JSCEP" format="default">JSCEP project</xref> in the src/samples directory.

      </t>
      <section anchor="message-processing" title="SCEP numbered="true" toc="default">
        <name>SCEP Message Object Processing"> Processing</name>
        <t>

Creating a SCEP message consists of several stages.  The content to be
conveyed (in other words words, the messageData) is first encrypted, and the
encrypted content is then signed.

        </t>
        <t>

The form of encryption to be applied depends on the capabilities of the
recipient's public key.  If the key is encryption-capable encryption capable (for example RSA) example, RSA),
then the messageData is encrypted using the recipient's public key with the
CMS KeyTransRecipientInfo mechanism.  If the key is not encryption-capable encryption capable
(for example example, DSA or ECDSA) ECDSA), then
the messageData is encrypted using the
challengePassword with the CMS PasswordRecipientInfo mechanism.

        </t>
        <t>

Once the messageData has been encrypted, it is signed with the sender's public
key.  This completes the SCEP message that message, which is then sent to the recipient.

        </t>
        <t>

Note that some early implementations of this specification dealt with
non-encryption-capable keys
that were not encryption capable by omitting the encryption stage, based on the
text in <xref target="message-obj"/> target="message-obj" format="default"/> that indicated that "the EnvelopedData is
omitted".  This alternative processing mechanism SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used since it
exposes in cleartext the challengePassword used to authorise the certificate
issue.

        </t>
        <t>

        </t>
      </section>
      <section anchor="pkiMessage" title="SCEP pkiMessage"> numbered="true" toc="default">
        <name>SCEP pkiMessage</name>
        <t>

The basic building block of all secured SCEP messages is the SCEP pkiMessage.
It consists of a CMS Signed-Data SignedData content type.  The following restrictions
apply:

        </t>
		<t>

		<list style="symbols">

		  <t>The
        <ul spacing="compact">
          <li>The eContentType in encapsulatedContentInfo MUST <bcp14>MUST</bcp14> be data ({pkcs-7
		     1}).</t>

		  <t>The
		     1}).</li>
          <li>The signed content, if present (FAILURE and PENDING CertRep
			 messages will lack any signed content), MUST
			 <bcp14>MUST</bcp14> be a pkcsPKIEnvelope
			 (<xref target="pkcsPKIEnvelope"/>), target="pkcsPKIEnvelope" format="default"/>)
			 and MUST <bcp14>MUST</bcp14> match the
			 messageType attribute.</t>

		  <t>The attribute.</li>
          <li>The SignerInfo MUST <bcp14>MUST</bcp14> contain a set of authenticatedAttributes
			 (<xref target="signed-attrs"/>).</t>

		</list>
		</t> target="signed-attrs" format="default"/>).</li>
        </ul>
        <section anchor="signed-attrs" title="Signed numbered="true" toc="default">
          <name>Signed Transaction Attributes"> Attributes</name>
          <t>

At a minimum, all messages MUST <bcp14>MUST</bcp14> contain the following authenticatedAttributes:

          </t>
		  <t>

		  <list style="symbols">

			<t>A
          <ul spacing="compact">
            <li>A transactionID attribute (see <xref
			   target="transactionID"/>).</t>

			<t>A target="transactionID" format="default"/>).</li>
            <li>A messageType attribute (see <xref target="messageType"/>).</t>

			<t>A target="messageType" format="default"/>).</li>
            <li>A fresh senderNonce attribute (see <xref
			   target="nonces"/>).  Note however target="nonces"
	    format="default"/>).  However, note the comment about
	    senderNonces and polling in <xref target="CertRep"/> </t>

			<t>Any target="CertRep" format="default"/> </li>
            <li>Any attributes required by CMS.</t>

		  </list>

		  </t> CMS.</li>
          </ul>
          <t>

If the message is a CertRep, it MUST <bcp14>MUST</bcp14> also include the following
authenticatedAttributes:

          </t>
		  <t>

		  <list style="symbols">

			<t>A
          <ul spacing="compact">
            <li>A pkiStatus attribute (see <xref target="pkiStatus"/>).</t>

			<t>A failInfo target="pkiStatus" format="default"/>).</li>
            <li>failInfo and optional failInfotext attribute failInfoText attributes (see <xref
			   target="failInfo"/>)
	    target="failInfo" format="default"/>) if pkiStatus = FAILURE.</t>

			<t>A FAILURE.</li>
            <li>A recipientNonce attribute (see <xref target="nonces"/>) target="nonces" format="default"/>) copied
	    from the senderNonce in the request that this is a response
			   to.</t>

		  </list>

		  </t>
	    to.</li>
          </ul>
          <t>

The following transaction attributes are encoded as authenticated attributes, attributes
and are carried in the SignerInfo for this Signed-Data. SignedData.

          </t>
		  <texttable
          <table align="left">
			<ttcol>Attribute</ttcol>
			<ttcol>Encoding</ttcol>
			<ttcol>Comment</ttcol>

			<c>transactionID</c><c>PrintableString</c><c>Unique
	    <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</c>

			<c>messageType</c><c>PrintableString</c><c>Decimal string</td>
              </tr>
              <tr>
                <td align="left">messageType</td>
                <td align="left">PrintableString</td>
                <td align="left">Decimal value as a
			numeric text string</c>

			<c>pkiStatus</c><c>PrintableString</c><c>Decimal string</td>
              </tr>
              <tr>
                <td align="left">pkiStatus</td>
                <td align="left">PrintableString</td>
                <td align="left">Decimal value as a
			numeric text string</c>

			<c>failInfo</c><c>PrintableString</c><c>Decimal string</td>
              </tr>
              <tr>
                <td align="left">failInfo</td>
                <td align="left">PrintableString</td>
                <td align="left">Decimal value as a
			numeric text string</c>

			<c>failInfoText</c><c>UTF8String</c><c>Descriptive string</td>
              </tr>
              <tr>
                <td align="left">failInfoText</td>
                <td align="left">UTF8String</td>
                <td align="left">Descriptive text for the
			failInfo value</c>

			<c>senderNonce</c><c>OCTET STRING</c><c>Random 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</c>

			<c>recipientNonce</c><c>OCTET STRING</c><c>Random 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</c>

		  </texttable>

		  <texttable align="left">
			<preamble>The string</td>
              </tr>
            </tbody>
          </table>
          <t>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
			          follows:</t>

          <table align="left">
	    <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)}</c>

			<c>id-pki</c><c>OBJECT_IDENTIFIER
			   VeriSign(113733)}</td>
              </tr>
              <tr>
                <td align="left">id-pki</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)}</c>

			<c>id-attributes</c><c>OBJECT_IDENTIFIER pki(1)}</td>
              </tr>
              <tr>
                <td align="left">id-attributes</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-pki
			   attributes(9)}</c>

			<c>id-transactionID</c><c>OBJECT_IDENTIFIER
			   attributes(9)}</td>
              </tr>
              <tr>
                <td align="left">id-transactionID</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
			   transactionID(7)}</c>

			<c>id-messageType</c><c>OBJECT_IDENTIFIER
			   transactionID(7)}</td>
              </tr>
              <tr>
                <td align="left">id-messageType</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
			   messageType(2)}</c>

			<c>id-pkiStatus</c><c>OBJECT_IDENTIFIER
			   messageType(2)}</td>
              </tr>
              <tr>
                <td align="left">id-pkiStatus</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
			   pkiStatus(3)}</c>

			<c>id-failInfo</c><c>OBJECT_IDENTIFIER
			   pkiStatus(3)}</td>
              </tr>
              <tr>
                <td align="left">id-failInfo</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
			   failInfo(4)}</c>

			<c>id-senderNonce</c><c>OBJECT_IDENTIFIER
			   failInfo(4)}</td>
              </tr>
              <tr>
                <td align="left">id-senderNonce</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
			   senderNonce(5)}</c>

			<c>id-recipientNonce</c><c>OBJECT_IDENTIFIER
			   senderNonce(5)}</td>
              </tr>
              <tr>
                <td align="left">id-recipientNonce</td>
                <td align="left">OBJECT_IDENTIFIER ::= {id-attributes
				recipientNonce(6)}</c>

			<c>id-scep</c><c>OBJECT
				recipientNonce(6)}</td>
              </tr>
              <tr>
                <td align="left">id-scep</td>
                <td align="left">OBJECT IDENTIFIER ::= {id-pkix TBD1}</c>

			<c>id-scep-failInfoText</c><c>OBJECT 24}</td>
              </tr>
              <tr>
                <td align="left">id-scep-failInfoText</td>
                <td align="left">OBJECT IDENTIFIER ::= {id-scep 1}</c>

		  </texttable> 1}</td>
              </tr>
            </tbody>
          </table>
          <t>

The attributes are detailed in the following sections.

          </t>
          <section anchor="transactionID" title="transactionID"> numbered="true" toc="default">
            <name>transactionID</name>
            <t>

A PKI operation is a transaction consisting of the messages exchanged between
a client and the CA.  The transactionID is a text string provided by the
client when starting a transaction.  The client MUST <bcp14>MUST</bcp14> use a unique string as
the transaction identifier, encoded as a PrintableString, which MUST <bcp14>MUST</bcp14> be used
for all PKI messages exchanged for a given operation operation, such as a certificate
issue.

            </t>
            <t>

Note that the transactionID must be unique, but not necessarily randomly
generated.  For example 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 device's EUI or RTU ID Extended Unique Identifier (EUI), Remote Terminal Unit (RTU) ID, or a similar unique
identifier.  This can be
useful when the client doesn't have a pre-assigned preassigned Distinguished Name that through
which the CA can identify their request through, -- for example example, when enrolling SCADA
Supervisory Control and Data Acquisition (SCADA) devices.

            </t>
          </section>
          <section anchor="messageType" title="messageType"> numbered="true" toc="default">
            <name>messageType</name>
            <t>
The messageType attribute specifies the type of operation performed by the
transaction.  This attribute MUST <bcp14>MUST</bcp14> be included in all PKI messages.  The
following message types are defined:
            </t>
			<t>

			<list style="symbols">

			  <t>CertRep ("3") -- Response

<table anchor="scep-message-types">
  <name>SCEP Message Types</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>

    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td></td>
    </tr>
    <tr>
      <td>3</td>
      <td>CertRep</td>
      <td>Response to certificate or CRL request.</t>

			  <t>RenewalReq ("17") -- PKCS request.</td>
    </tr>
    <tr>
      <td>17</td>
      <td>RenewalReq</td>
      <td>PKCS #10 certificate request authenticated with an existing certificate.</t>

			  <t>PKCSReq ("19") -- PKCS certificate.</td>
    </tr>
    <tr>
      <td>19</td>
      <td>PKCSReq</td>
      <td>PKCS #10 certificate request authenticated with a shared secret.</t>

			  <t>CertPoll ("20") -- Certificate secret.</td>
    </tr>
    <tr>
      <td>20</td>
      <td>CertPoll</td>
      <td>Certificate polling in manual enrolment.</t>

			  <t>GetCert ("21") -- Retrieve a certificate.</t>

			  <t>GetCRL ("22") -- Retrieve a CRL.</t>

			</list>

			</t> 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>

<t>
Message types not defined above MUST <bcp14>MUST</bcp14> be treated as an error errors unless their use
has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. target="CA-caps-HTTP" format="default">GetCACaps</xref>.

            </t>
          </section>
          <section anchor="pkiStatus" title="pkiStatus"> numbered="true" toc="default">
            <name>pkiStatus</name>
            <t>

All response messages MUST <bcp14>MUST</bcp14> include transaction status information, which is
defined as a pkiStatus attribute:
            </t>
			<t>

			<list style="symbols">

			  <t>SUCCESS ("0") -- Request granted.</t>

			  <t>FAILURE ("2") -- Request

<table anchor="tab-pkiStatus">
  <name>pkiStatus Attributes</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>SUCCESS</td>
      <td>Request granted.</td>
    </tr>
    <tr>
      <td>2</td>
      <td>FAILURE</td>
      <td>Request rejected.  In this case case, the failInfo attribute, as defined
      in <xref target="failInfo"/>, MUST target="failInfo" format="default"/>, <bcp14>MUST</bcp14> also
      be present.</t>

			  <t>PENDING ("3") -- Request present.</td>
    </tr>
    <tr>
      <td>3</td>
      <td>PENDING</td>
      <td>Request pending for manual approval.</t>

			</list>

			</t> approval.</td>
    </tr>
  </tbody>
</table>

<t>
PKI status values not defined above MUST <bcp14>MUST</bcp14> be treated as an error errors unless their
use has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. target="CA-caps-HTTP" format="default">GetCACaps</xref>.
            </t>
          </section>
          <section anchor="failInfo" title="failInfo numbered="true" toc="default">
            <name>failInfo and failInfoText"> failInfoText</name>
            <t>
The failInfo attribute MUST <bcp14>MUST</bcp14> contain one of the following failure reasons:
            </t>
			<t>

			<list style="symbols">

			  <t>badAlg ("0") -- Unrecognized

<table anchor="tab-failInfo">
  <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.</t>

			  <t>badMessageCheck ("1") -- Integrity algorithm.</td>
    </tr>
    <tr>
      <td>1</td>
      <td>badMessageCheck</td>
      <td>Integrity check (meaning signature verification of the CMS message) failed.</t>

			  <t>badRequest ("2") -- Transaction failed.</td>
    </tr>
    <tr>
      <td>2</td>
      <td>badRequest</td>
      <td>Transaction not permitted or
			     supported.</t>

			  <t>badTime ("3") -- The 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.</t>

			  <t>badCertId ("4") -- No messages.</td>
    </tr>
    <tr>
      <td>4</td>
      <td>badCertId</td>
      <td>No certificate could be identified matching the provided criteria.</t>

			</list>

			</t> criteria.</td>
    </tr>
  </tbody>
</table>

            <t>
Failure reasons not defined above MUST <bcp14>MUST</bcp14> be treated as an error errors unless their use
has been negotiated through <xref target="CA-caps-HTTP">GetCACaps</xref>. target="CA-caps-HTTP" format="default">GetCACaps</xref>.
            </t>
            <t>
The failInfoText is a free-form UTF-8 text string that provides further
information in the case of pkiStatus = FAILURE.  In particular particular, it may be used
to provide details on why a certificate request was not granted that go beyond
what's provided by the near-universal failInfo = badRequest status.  Since
this is a free-form text string intended for interpretation by humans,
implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> assume that it has any type of machine-processable
content.
            </t>
          </section>
          <section anchor="nonces" title="senderNonce numbered="true" toc="default">
            <name>senderNonce and recipientNonce"> recipientNonce</name>
            <t>
The senderNonce and recipientNonce attributes are each a 16 byte 16-byte random number
generated for each transaction.  These are intended to prevent replay attacks.
            </t>
            <t>
When a sender sends a PKI message to a recipient, a fresh senderNonce MUST <bcp14>MUST</bcp14> be
included in the message.  The recipient MUST <bcp14>MUST</bcp14> copy the senderNonce into the
recipientNonce of the reply as a proof of liveliness.  The original sender
MUST
<bcp14>MUST</bcp14> verify that the recipientNonce of the reply matches the senderNonce it
sent in the request.  If the nonce does not match match, then the message MUST <bcp14>MUST</bcp14> be
rejected.
            </t>
            <t>
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 redundant,
since the client sends a nonce in its request and the CA responds with the
same nonce in its reply.  In effect effect, there's just a single nonce, identified as
senderNonce in the client's request and recipientNonce in the CA's reply.
            </t>
          </section>
        </section>
        <section anchor="pkcsPKIEnvelope" title="SCEP pkcsPKIEnvelope"> numbered="true" toc="default">
          <name>SCEP pkcsPKIEnvelope</name>
          <t>

The information portion of a SCEP message is carried inside an EnvelopedData
content type, as defined in CMS, with the following restrictions:

          </t>
		  <t>

		  <list style="symbols">

			<t>contentType
          <ul spacing="compact">
            <li>contentType in encryptedContentInfo MUST <bcp14>MUST</bcp14> be data ({pkcs-7
			   1}).</t>

			<t>encryptedContent MUST
			   1}).</li>

            <li>encryptedContent <bcp14>MUST</bcp14> be the SCEP message being transported
			   (see <xref target="SCEP-trans"/>), target="SCEP-trans" format="default"/>)
			   and must <bcp14>MUST</bcp14> match the
			   messageType authenticated Attribute in the pkiMessage.</t>

		  </list>

		  </t> pkiMessage.</li>
          </ul>
        </section>
      </section>
      <section anchor="pkiMessage-types" title="SCEP numbered="true" toc="default">
        <name>SCEP pkiMessage types"> types</name>
        <t>

All of the messages in this section are pkiMessages (<xref
target="pkiMessage"/>), target="pkiMessage" format="default"/>), where the type of the message MUST <bcp14>MUST</bcp14> be specified in the
'messageType'
"messageType" authenticated Attribute.  Each section defines a valid message
type, the corresponding messageData formats, and mandatory authenticated
attributes for that type.

        </t>
        <section anchor="PKCSReq" title="PKCSReq/RenewalReq"> numbered="true" toc="default">
          <name>PKCSReq/RenewalReq</name>
          <t>

The messageData for this type consists of a PKCS #10 Certificate Request.  The
certificate request MUST <bcp14>MUST</bcp14> contain at least the following items:

          </t>
		  <t>

		  <list style="symbols">

			<t>The
          <ul spacing="compact">
            <li>The subject Distinguished Name.</t>

			<t>The Name.</li>
            <li>The subject public key.</t>

			<t>For key.</li>
            <li>For a PKCSReq and PKCSReq, if authorisation based on a shared secret is
	    being used, a challengePassword attribute.</t>

		  </list>

		  </t> attribute.</li>
          </ul>
          <t>

In addition addition, the message must contain the the authenticatedAttributes specified in
<xref target="signed-attrs"/>. target="signed-attrs" format="default"/>.

          </t>
        </section>
        <section anchor="CertRep" title="CertRep"> numbered="true" toc="default">
          <name>CertRep</name>
          <t>

The messageData for this type consists of a degenerate certificates-only CMS
Signed-Data
SignedData message (<xref target="certs-only"/>). target="certs-only" format="default"/>).  The exact content required
for the reply depends on the type of request that this message is a response
to.  The request types are detailed in Sections <xref target="CertRep-success"/> target="CertRep-success"
format="counter"/> and in <xref target="SCEP-trans"/>. target="SCEP-trans" format="counter"/>.  In addition
addition, the message must contain the the
authenticatedAttributes specified in <xref target="signed-attrs"/>. target="signed-attrs" format="default"/>.

          </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
subsequent polling operations.  However  However, if a single message was lost during
the potentially extended interval over which polling could take place (see
<xref target="state-trans"/> target="state-trans" format="default"/> for an example of this) this), then if the
implementation were to enforce this requirement requirement, the overall transaction would
fail
fail, even though nothing had actually gone wrong.  Because of this issue,
implementations mostly ignored the requirement to either carry this nonce over to
subsequent polling messages or to verify its presence.  More recent versions
of the specification no longer require the chaining of nonces across polling
operations.

          </t>
          <section anchor="CertRep-success" title="CertRep SUCCESS"> numbered="true" toc="default">
            <name>CertRep SUCCESS</name>
            <t>

When the pkiStatus attribute is set to SUCCESS, the messageData for this
message consists of a degenerate certificates-only CMS Signed-Data SignedData message
(<xref target="certs-only"/>). target="certs-only" format="default"/>).  The content of this degenerate
certificates-only Signed-Data SignedData message depends on what the original request was, as
outlined below. in <xref target="success"/>.

            </t>
			<texttable align="left">

			  <ttcol>Request-type</ttcol>
			  <ttcol>Reply-contents</ttcol>

			  <c>PKCSReq</c><c>The
            <table align="left" anchor="success">
	      <name>CertRep Response Types</name>
              <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 MUST <bcp14>MUST</bcp14> contain at least the issued
		  certificate in the certificates field of the Signed-Data. SignedData.
		  The reply MAY <bcp14>MAY</bcp14> contain additional certificates, but the issued
		  certificate MUST <bcp14>MUST</bcp14> 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 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 MUST <bcp14>MUST</bcp14> contain at least the requested
				 certificate in the certificates field of the Signed-Data. SignedData.
				 The reply MAY <bcp14>MAY</bcp14> contain additional certificates, but the
				 requested certificate MUST <bcp14>MUST</bcp14> be the leaf certificate.</c>

			  <c>GetCRL</c><c>The certificate.</td>
                </tr>
                <tr>
                  <td align="left">GetCRL</td>
                  <td align="left">The reply MUST <bcp14>MUST</bcp14> contain the
		  CRL in the crls field of the Signed-Data.</c>

			</texttable> SignedData.</td>
                </tr>
              </tbody>
            </table>
          </section>
          <section anchor="CertRep-failure" title="CertRep FAILURE"> numbered="true" toc="default">
            <name>CertRep FAILURE</name>
            <t>

When the pkiStatus attribute is set to FAILURE, the reply MUST <bcp14>MUST</bcp14> also contain a
failInfo (<xref target="failInfo"/>) target="failInfo" format="default"/>) attribute set to the appropriate error
condition describing the failure.  The reply MAY <bcp14>MAY</bcp14> also contain a failInfoText
attribute providing extended details on why the operation failed, typically to
expand on the catch-all catchall failInfo = badRequest status.  The pkcsPKIEnvelope
(<xref target="pkcsPKIEnvelope"/>) MUST target="pkcsPKIEnvelope" format="default"/>) <bcp14>MUST</bcp14> be omitted.

            </t>
          </section>
          <section anchor="CertRep-pending" title="CertRep PENDING"> numbered="true" toc="default">
            <name>CertRep PENDING</name>
            <t>

When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (<xref
target="pkcsPKIEnvelope"/>) MUST target="pkcsPKIEnvelope" format="default"/>) <bcp14>MUST</bcp14> be omitted.

            </t>
          </section>
        </section>
        <section anchor="CertPoll" title="CertPoll (GetCertInitial)"> numbered="true" toc="default">
          <name>CertPoll (GetCertInitial)</name>
          <t>
This message is used for certificate polling.  For unknown reasons reasons, it was
referred to as "GetCertInitial" in earlier draft versions of this specification.
The messageData for this type consists of an IssuerAndSubject:
          </t>

		  <figure>
			<artwork><![CDATA[

<sourcecode>
issuerAndSubject ::= SEQUENCE {
    issuer     Name,
    subject    Name
    }

			]]></artwork>
		  </figure>
</sourcecode>

          <t>
The issuer is set to the subjectName of the CA (in other words words, the intended
issuerName of the certificate that's being requested).  The subject is set to
the subjectName used when requesting the certificate.
          </t>

          <t>
Note that both of these fields are redundant, redundant; the CA is identified by the
recipientInfo in the pkcsPKIEnvelope (or in most cases cases, simply by the server
that the message is being sent to) to), and the client/transaction being polled is
identified by the transactionID.  Both of these fields can be processed by the
CA without going through the cryptographically expensive process of unwrapping
and processing the issuerAndSubject.  For this reason reason, implementations SHOULD <bcp14>SHOULD</bcp14>
assume that the polling operation will be controlled by the recipientInfo and
transactionID rather than the contents of the messageData.  In addition addition, the
message must contain the the authenticatedAttributes specified in <xref
target="signed-attrs"/>.
target="signed-attrs" format="default"/>.

          </t>
        </section>
        <section anchor="GetCertCRL" title="GetCert numbered="true" toc="default">
          <name>GetCert and GetCRL"> GetCRL</name>
          <t>

The messageData for these types consist of an IssuerAndSerialNumber IssuerAndSerialNumber, as defined
in CMS which CMS, that uniquely identifies the certificate being requested, either the
certificate itself for GetCert or its revocation status via a CRL for GetCRL.
In addition addition, the message must contain the the authenticatedAttributes specified
in <xref target="signed-attrs"/>. target="signed-attrs" format="default"/>.

          </t>
          <t>

These message types, while included here for completeness, apply unnecessary
cryptography and messaging overhead to the simple task of transferring a
certificate or CRL (see <xref target="security-unnecessary"/>). target="security-unnecessary" format="default"/>).
Implementations SHOULD <bcp14>SHOULD</bcp14> prefer
<xref target="HTTP-certstore">HTTP target="RFC4387" format="default">HTTP certificate-store access</xref> or LDAP
over the use of these messages.

          </t>
        </section>
      </section>
      <section anchor="certs-only" title="Degenerate numbered="true" toc="default">
        <name>Degenerate certificates-only CMS Signed-Data"> SignedData</name>

        <t>
CMS includes a degenerate case of the Signed-Data SignedData content type in which there
are no signers.  The use of such a degenerate case is to disseminate
certificates and CRLs.  For SCEP SCEP, the content field of the ContentInfo value of
a degenerate certificates-only Signed-Data MUST SignedData <bcp14>MUST</bcp14> be omitted.  When carrying
certificates, the certificates are included in the 'certificates' certificates field of the
Signed-Data.
SignedData.  When carrying a CRL, the CRL is included in the 'crls' crls field of
the Signed-Data. SignedData.
        </t>
      </section>
      <section anchor="CA-caps" title="CA Capabilities"> numbered="true" toc="default">
        <name>CA Capabilities</name>
        <t>

In order to provide support for future enhancements to the protocol, CAs MUST <bcp14>MUST</bcp14>
implement the GetCACaps message to allow clients to query which functionality
is available from the CA.

        </t>
        <section anchor="CA-caps-HTTP" title="GetCACaps numbered="true" toc="default">
          <name>GetCACaps HTTP Message Format">

		  <figure>
		    <preamble>This Format</name>
          <t>This message requests capabilities from a CA, with the
					  format:</preamble>
		    <artwork><![CDATA[
	  format as described in <xref target="HTTP-GET-POST" format="default"/>:</t>

<sourcecode type="">
"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF

		    ]]></artwork>
		  </figure>

		  <t>

as described in <xref target="HTTP-GET-POST"/>.

		  </t>
</sourcecode>

        </section>

        <section anchor="CA-caps-resp" title="CA numbered="true" toc="default">
          <name>CA Capabilities Response Format">

		  <texttable align="left">
		    <preamble>The Format</name>
          <t>The response for a GetCACaps message is a list of CA
					  capabilities, in plain text and in any order, separated
					  by &lt;CR&gt;&lt;LF&gt; or &lt;LF&gt; characters.  This
					  specification defines the following keywords (quotation
					  marks are not sent):</preamble>
		    <ttcol>Keyword</ttcol>
		    <ttcol>Description</ttcol>

		    <c>"AES"</c><c>CA sent):</t>
          <table align="left" anchor="keywords">
	    <name>GetCACaps Response Keywords</name>
            <thead>
              <tr>
                <th align="left">Keyword</th>
                <th align="left">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">AES</td>
                <td align="left">CA supports the AES128-CBC encryption
			   algorithm.</c>

		    <c>"DES3"</c><c>CA
			   algorithm.</td>
              </tr>
              <tr>
                <td align="left">DES3</td>
                <td align="left">CA supports the triple DES-CBC encryption
			   algorithm.</c>

		    <c>"GetNextCACert"</c><c>CA
			   algorithm.</td>
              </tr>
              <tr>
                <td align="left">GetNextCACert</td>
                <td align="left">CA supports the GetNextCACert
				message.</c>

		    <c>"POSTPKIOperation"</c><c>CA
				message.</td>
              </tr>
              <tr>
                <td align="left">POSTPKIOperation</td>
                <td align="left">CA supports PKIOPeration messages sent
			   via HTTP POST.</c>

		    <c>"Renewal"</c><c>CA POST.</td>
              </tr>
              <tr>
                <td align="left">Renewal</td>
                <td align="left">CA supports the Renewal CA operation.</c>

		    <c>"SHA-1"</c><c>CA operation.</td>
              </tr>
              <tr>
                <td align="left">SHA-1</td>
                <td align="left">CA supports the SHA-1 hashing algorithm.</c>

		    <c>"SHA-256"</c><c>CA algorithm.</td>
              </tr>
              <tr>
                <td align="left">SHA-256</td>
                <td align="left">CA supports the SHA-256 hashing algorithm.</c>

		    <c>"SHA-512"</c><c>CA algorithm.</td>
              </tr>
              <tr>
                <td align="left">SHA-512</td>
                <td align="left">CA supports the SHA-512 hashing algorithm.</c>

		    <c>"SCEPStandard"</c><c>CA 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",
			"POSTPKIOperation", and "SHA-256", as well as the provisions of
			<xref target="MTI"/>.</c>

		  </texttable> target="MTI" format="default"/>.</td>
              </tr>
            </tbody>
          </table>
          <t>

The table above

<xref target="keywords" /> lists all of the keywords that are defined in this
specification.  A CA MAY <bcp14>MAY</bcp14> provide additional keywords advertising further
capabilities and functionality.  A client MUST <bcp14>MUST</bcp14> be able to accept and ignore
any unknown keywords that might be sent by a CA.
          </t>
          <t>
The CA MUST <bcp14>MUST</bcp14> use the text case specified here, but clients SHOULD
<bcp14>SHOULD</bcp14> ignore the text case when processing this message.
Clients MUST <bcp14>MUST</bcp14> accept the standard
HTTP-style &lt;CR&gt;&lt;LF&gt;-delimited text delimited by &lt;CR&gt;&lt;LF&gt; as well as the &lt;LF&gt;-
delimited
text delimited by &lt;LF&gt; specified in an earlier draft version of this
specification.
          </t>
          <t>
The client SHOULD <bcp14>SHOULD</bcp14> 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
CMS format allows any form of  AES and SHA-2 to be specified, in the interests
of interoperability the de facto universal standards of AES128-CBC and SHA-256
SHOULD
<bcp14>SHOULD</bcp14> be used.
          </t>
          <t>
Announcing some of these capabilities individually is redundant redundant, since they're
required as mandatory-to-implement functionality (see <xref target="MTI"/>) target="MTI" format="default"/>)
whose presence as a whole is signalled by the "SCEPStandard" capability, but capability. However,
it may be useful to announce them in order to deal with older implementations
that would otherwise default to obsolete, insecure algorithms and mechanisms.

          </t>
          <t>

If the CA supports none of the above capabilities capabilities, it SHOULD <bcp14>SHOULD</bcp14> return an empty
message.  A CA MAY <bcp14>MAY</bcp14> simply return an HTTP error.  A client that receives an
empty message or an HTTP error SHOULD <bcp14>SHOULD</bcp14> interpret the response as if none of the
capabilities listed are supported by the CA.

          </t>
          <t>

Note that at least one widely-deployed widely deployed server implementation supports several
of the above operations but doesn't support the GetCACaps message to indicate
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
through server fingerprinting, which can be done using the ID string
"Microsoft-IIS".  Newer versions of the same server, if sent a SCEP request
using AES and SHA-2, will respond with an invalid response that can't be
decrypted, requiring the use of 3DES and SHA-1 in order to obtain a response
that can be processed processed, even if AES and/or SHA-2 are allegedly supported.  In
addition
addition, the server will generate CA certificates that only have one, but not
both, of the keyEncipherment and digitalSignature keyUsage flags set,
requiring that the client ignore the keyUsage flags in order to use the
certificates for SCEP.

          </t>
          <t>

The Content-type of the reply SHOULD <bcp14>SHOULD</bcp14> be "text/plain".  Clients SHOULD
<bcp14>SHOULD</bcp14> ignore
the Content-type, as older implementations of SCEP may send various
Content-types.
          </t>
		  <figure>
		    <preamble>Example:</preamble>
		    <artwork><![CDATA[

          <t>Example:</t>
<sourcecode>
GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1

		    ]]></artwork>
		  </figure>

		  <figure>
		    <preamble>might return:</preamble>
		    <artwork><![CDATA[
</sourcecode>

          <t>might return:</t>
<sourcecode>
AES
GetNextCACert
POSTPKIOperation
SCEPStandard
SHA-256

		    ]]></artwork>
		  </figure>
</sourcecode>
          <t>

This means that the CA supports modern crypto algorithms, and the GetNextCACert
message,
message allows PKIOperation messages (PKCSReq/RenewalReq, GetCert, CertPoll,
...) to be sent using HTTP POST, POST and is compliant with the final version of
the SCEP standard.

          </t>
        </section>
      </section>
    </section>
    <section anchor="SCEP-trans" title="SCEP Transactions"> numbered="true" toc="default">
      <name>SCEP Transactions</name>
      <t>

This section describes the SCEP Transactions and their
<xref target="HTTP">HTTP</xref> target="RFC7230" format="default">HTTP</xref> transport mechanism.

      </t>
      <t>

Note that SCEP doesn't follow best current practices on usage of HTTP.  In
particular
particular, it recommends ignoring some Media Types media types and hardcodes hard-codes specific URI
paths.  Guidance on the appropriate application of HTTP in these circumstances
may be found in <xref target="BCP56bis"/>. target="I-D.ietf-httpbis-bcp56bis" format="default"/>.

      </t>
      <section anchor="HTTP-GET-POST" title="HTTP numbered="true" toc="default">
        <name>HTTP POST and GET Message Formats"> Formats</name>
        <t>

SCEP uses the HTTP "POST" POST and "GET" HTTP GET methods <xref target="HTTP"/> target="RFC7230" format="default"/> to
exchange information with the CA.  The following defines the ABNF syntax of
HTTP POST and GET methods sent from a client to a CA:

        </t>
		<figure>
		  <artwork><![CDATA[
<sourcecode type="abnf">
POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION
              SP HTTP-version CRLF

GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
             "&message="
             "&amp;message=" MESSAGE SP HTTP-version CRLF

		  ]]></artwork>
		</figure>
</sourcecode>

        <t>
where:

        </t>
        <t>

      	<list style="symbols">

		  <t>SCEPPATH
        <ul spacing="compact">
          <li>SCEPPATH is the HTTP URL path for accessing the CA. Clients
		  SHOULD
		  <bcp14>SHOULD</bcp14> set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe"
		  unless directed to do otherwise by the CA.</t>

		  <t>OPERATION CA.</li>
          <li>OPERATION depends on the SCEP transaction and is defined in the
		  following sections.</t>

		  <t>HTTP-version sections.</li>
          <li>HTTP-version is the HTTP version string, which is "HTTP/1.1" for
		  <xref target="HTTP"/>.</t>

		  <t>SP target="RFC7230" format="default"/>.</li>
          <li>SP and CRLF are space and carriage return/linefeed return/linefeed, as defined in
		  <xref target="ABNF"/>.</t>

        </list>

        </t> target="RFC5234" format="default"/>.</li>
        </ul>
        <t>

The CA will typically ignore SCEPPATH SCEPPATH, since it's unlikely to be issuing
certificates via a web server.  Clients SHOULD <bcp14>SHOULD</bcp14> set SCEPPATH to the fixed
string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA.
The CA SHOULD <bcp14>SHOULD</bcp14> ignore the SCEPPATH unless its precise format is critical to the
CA's operation.

        </t>
        <t>
Early SCEP drafts performed all communications via "GET" GET messages, including
non-idempotent ones that should have been sent via "POST" messages, POST messages; see
<xref target="BCP56bis"/> target="I-D.ietf-httpbis-bcp56bis" format="default"/> for details.  This has caused problems because of
the way that the (supposedly) idempotent GET interacts with caches and
proxies, and because the extremely large GET requests created by encoding CMS
messages may be truncated in transit.  These issues are typically not visible
when testing on a LAN, but crop up during deployment over WANs.  If the remote
CA supports POST, the CMS-encoded SCEP messages MUST <bcp14>MUST</bcp14> be sent via HTTP POST
instead of HTTP GET.  This applies to any SCEP message except GetCACert,
GetNextCACert, and GetCACaps, GetCACaps and avoids the need for base64- base64 and URL-encoding URL encoding
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"
capability (See (see <xref target="CA-caps-resp"/>). target="CA-caps-resp" format="default"/>).

        </t>
        <t>
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 ("Request-URI too
long"), or simply having the message not sent/received at all, all when standard
requests to the server (for example example, via a web browser) work, then this is a
symptom of the problematic use of HTTP GET.  The solution to this problem is
to update the implementation to use HTTP POST instead.  In addition addition, when using
GET
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
with communications.

        </t>
        <t>

When using GET messages to communicate binary data, base64 encoding as
specified in <xref target="Base64"/> Section 4 MUST target="RFC4648" sectionFormat="of" section="4"/>
<bcp14>MUST</bcp14> be used.  The base64
encoded base64-encoded data is distinct from
"base64url" and may contain URI reserved
characters, thus
characters; thus, it MUST <bcp14>MUST</bcp14> be escaped as specified in <xref target="URI"/>
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.

        </t>
      </section>
      <section anchor="GetCACert" title="Get numbered="true" toc="default">
        <name>Get CA Certificate"> Certificate</name>
        <t>

To get the CA certificate(s), the client sends a GetCACert message to the CA.
The OPERATION MUST <bcp14>MUST</bcp14> be set to "GetCACert".  There is no request data associated
with this message.

        </t>
        <section anchor="GetCACert-resp" title="Get numbered="true" toc="default">
          <name>Get CA Certificate Response Message Format"> Format</name>
          <t>

The response for GetCACert is different between the case where the CA directly
communicates with the client during the enrolment and the case where an
intermediate CA exists and the client communicates with this CA during the
enrolment.

          </t>
          <section anchor="GetCACert-resp-format" title="CA numbered="true" toc="default">
            <name>CA Certificate Response Message Format"> Format</name>
            <t>

If the CA does not have any intermediate CA certificates, the response
consists of a single X.509 CA certificate.  The response will have a
Content-Type of "application/x-x509-ca-cert".

            </t>
			<figure>
			  <artwork><![CDATA[
<sourcecode>
"Content-Type: application/x-x509-ca-cert"

<binary X.509>

			  ]]></artwork>
			</figure>

&lt;binary X.509&gt;
</sourcecode>
          </section>
          <section anchor="GetCACertChain-resp-format" title="CA numbered="true" toc="default">
            <name>CA Certificate Chain Response Message Format"> Format</name>
            <t>
If the CA has intermediate CA certificates, the response consists of a
degenerate certificates-only CMS Signed-Data SignedData message (<xref
target="certs-only"/>) target="certs-only" format="default"/>) containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s).  The response will have a
Content-Type of "application/x-x509-ca-ra-cert".  Note that this designation
is used for historical reasons due to its use in older versions of this
specification,
specification -- no special meaning should be attached to the label.
            </t>
			<figure>
			  <artwork><![CDATA[

<sourcecode>
"Content-Type: application/x-x509-ca-ra-cert"

<binary CMS>

			  ]]></artwork>
			</figure>

&lt;binary CMS&gt;
</sourcecode>
          </section>
        </section>
      </section>
      <section anchor="cert-enrolment" title="Certificate Enrolment/Renewal"> numbered="true" toc="default">
        <name>Certificate Enrolment/Renewal</name>
        <t>
A PKCSReq/RenewalReq (<xref target="PKCSReq"/>) target="PKCSReq" format="default"/>) message is used to perform a
certificate enrolment or renewal transaction.  The OPERATION MUST <bcp14>MUST</bcp14> be set to
"PKIOperation".  Note that when used with HTTP POST, the only OPERATION
possible is "PKIOperation", so many CAs don't check this value or even notice
its absence.  When implemented using HTTP POST POST, the message is sent with a
Content-Type of "application/x-pki-message" and might look as follows:
        </t>
		<figure>
		  <artwork><![CDATA[

<sourcecode>
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
Content-Length: <length &lt;length of data> data&gt;
Content-Type: application/x-pki-message

<binary

&lt;binary CMS data>

		  ]]></artwork>
		</figure> data&gt;
</sourcecode>
        <t>
	  When implemented using HTTP GET GET, this might look as follows:
        </t>
		<figure>
		  <artwork><![CDATA[

<sourcecode>
GET /cgi-bin/pkiclient.exe?operation=PKIOperation& /cgi-bin/pkiclient.exe?operation=PKIOperation&amp; \
message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1

		  ]]></artwork>
		</figure>
</sourcecode>

      <section anchor="cert-enrolment-resp" title="Certificate numbered="true" toc="default">
          <name>Certificate Enrolment/Renewal Response Message"> Message</name>
          <t>

If the request is granted, a CertRep SUCCESS message
(<xref target="CertRep-success"/>) target="CertRep-success" format="default"/>) is returned.  If the request is rejected, a
CertRep FAILURE message (<xref target="CertRep-failure"/>) target="CertRep-failure" format="default"/>) is returned.  If
the CA is configured to manually authenticate the client, a CertRep PENDING
message (<xref target="CertRep-pending"/>) MAY target="CertRep-pending" format="default"/>) <bcp14>MAY</bcp14> be returned.  The CA MAY <bcp14>MAY</bcp14> return
a PENDING for other reasons.

          </t>
          <t>
The response will have a Content-Type of "application/x-pki-message".
          </t>
		  <figure>
			<artwork><![CDATA[

<sourcecode>
"Content-Type: application/x-pki-message"

<binary

&lt;binary CertRep message>

			]]></artwork>
		  </figure> message&gt;
</sourcecode>
        </section>
      </section>
      <section anchor="poll-resp" title="Poll numbered="true" toc="default">
        <name>Poll for Client Initial Certificate"> Certificate</name>
        <t>

When the client receives a CertRep message with pkiStatus set to PENDING, it
will enter the polling state by periodically sending CertPoll messages to the
CA until either the request is granted and the certificate is sent back or the
request is rejected or some preconfigured time limit for polling or maximum
number of polls is exceeded.  The OPERATION MUST <bcp14>MUST</bcp14> be set to "PKIOperation".

        </t>
        <t>

CertPoll messages exchanged during the polling period MUST <bcp14>MUST</bcp14> carry the same
transactionID attribute as the previous PKCSReq/RenewalReq.  A CA receiving a
CertPoll for which it does not have a matching PKCSReq/RenewalReq MUST <bcp14>MUST</bcp14> reject
this request.

        </t>
        <t>

Since at this time the certificate has not been issued, the client can only
use its own subject name (which was contained in the original PKCS# 10 sent
via PKCSReq/RenewalReq) to identify the polled certificate request (but see
the note on identification during polling in <xref target="CertPoll"/>). target="CertPoll"
format="default"/>).  In
theory
theory, there can be multiple outstanding requests from one client (for
example, if different keys and different key-usages key usages were used to request
multiple certificates), so the transactionID must also be included to
disambiguate between multiple requests.  In practice however practice, however, the client SHOULD
NOT <bcp14>SHOULD
NOT</bcp14> have multiple requests outstanding at any one time, since this tends to
confuse some CAs.

        </t>
        <section anchor="poll-resp-format" title="Polling numbered="true" toc="default">
          <name>Polling Response Message Format"> Format</name>
          <t>

The response messages for CertPoll are the same as in <xref
target="cert-enrolment-resp"/>. target="cert-enrolment-resp" format="default"/>.

          </t>
        </section>
      </section>
      <section anchor="cert-access" title="Certificate Access"> numbered="true" toc="default">
        <name>Certificate Access</name>
        <t>

A client can query an issued certificate from the SCEP CA, as long as the
client knows the issuer name and the issuer assigned issuer-assigned certificate serial
number.

        </t>
        <t>

This transaction consists of one GetCert (<xref target="GetCertCRL"/>) target="GetCertCRL" format="default"/>) message
sent to the CA by a client, client and one CertRep (<xref target="CertRep"/>) target="CertRep" format="default"/>) message
sent back from the CA.  The OPERATION MUST <bcp14>MUST</bcp14> be set to "PKIOperation".

        </t>
        <section anchor="cert-access-resp" title="Certificate numbered="true" toc="default">
          <name>Certificate Access Response Message Format"> Format</name>
          <t>

In this case, the CertRep from the CA is same as in <xref
target="cert-enrolment-resp"/>, target="cert-enrolment-resp" format="default"/>, except that the CA will either grant the
request (SUCCESS) or reject it (FAILURE).

          </t>
        </section>
      </section>
      <section anchor="CRL-access" title="CRL Access"> numbered="true" toc="default">
        <name>CRL Access</name>
        <t>

Clients can request a CRL from the SCEP CA CA, as described in <xref
target="overview-CRL-access"/>.
target="overview-CRL-access" format="default"/>.  The OPERATION MUST
<bcp14>MUST</bcp14> be set to "PKIOperation".

        </t>
        <section anchor="CRL-access-resp" title="CRL numbered="true" toc="default">
          <name>CRL Access Response Message Format"> Format</name>
          <t>

The CRL is sent back to the client in a CertRep (<xref target="CertRep"/>) target="CertRep" format="default"/>)
message.  The information portion of this message is a degenerate
certificates-only Signed-Data SignedData (<xref target="certs-only"/>) target="certs-only"
format="default"/>) that contains only
the most recent CRL in the crls field of the Signed-Data. SignedData.

          </t>
        </section>
      </section>
      <section anchor="get-next-CA" title="Get numbered="true" toc="default">
        <name>Get Next Certificate Authority Certificate"> Certificate</name>
        <t>

When a CA certificate is about to expire, clients need to retrieve the CA's
next CA certificate (i.e. (i.e., the rollover certificate). This is done via the
GetNextCACert message.  The OPERATION MUST <bcp14>MUST</bcp14> be set to "GetNextCACert".  There
is no request data associated with this message.

        </t>
        <section anchor="get-next-CA-format" title="Get numbered="true" toc="default">
          <name>Get Next CA Response Message Format"> Format</name>
          <t>

The response consists of a Signed-Data SignedData CMS message, signed by the current CA
signing key.  Clients MUST <bcp14>MUST</bcp14> validate the signature on the message before
trusting any of its contents.  The response will have a Content-Type of
"application/x-x509-next-ca-cert".
          </t>
		  <figure>
			<artwork><![CDATA[

<sourcecode>
"Content-Type: application/x-x509-next-ca-cert"

<binary CMS>

			]]></artwork>
		  </figure>

&lt;binary CMS&gt;
</sourcecode>
          <t>

The content of the Signed-Data SignedData message is a degenerate certificates-only
Signed-Data
SignedData message (<xref target="certs-only"/>) target="certs-only" format="default"/>) containing the new CA
certificate(s) to be used when the current CA certificate expires.

          </t>
        </section>
      </section>
    </section>
    <!-- ====================================================================== -->

    <section anchor="state-trans" title="SCEP numbered="true" toc="default">
      <name>SCEP Transaction Examples"> Examples</name>
      <t>

The following section gives several examples of client to CA client-to-CA transactions.
Client actions are indicated in the left column, CA actions are indicated in
the right column, and the transactionID is given in parentheses (for parentheses. For ease of
reading
reading, small integer values have been used, used; in practice practice, full transaction IDs
would be used). used.  The first transaction, for example, would read like this:

      </t>
	  <t>

"Client
      <blockquote>
Client Sends PKCSReq message with transactionID 1 to the CA.  The CA signs
the certificate and constructs a CertRep Message containing the signed
certificate with a transaction ID 1.  The client receives the message and
installs the certificate locally".

	  </t> locally.
      </blockquote>
      <section title="Successful Transactions"> numbered="true" toc="default">
        <name>Successful Transactions</name>
<figure>
		  <preamble>Successful
<name>Successful Enrolment Case: Automatic processing</preamble>
		  <artwork><![CDATA[ Processing</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (1)             ----------> CA issues certificate
                        <---------- CertRep (1) SUCCESS
Client installs certificate
		  ]]></artwork>
</figure>

<figure>
		  <preamble>Successful
        <name>Successful Enrolment Case: Manual authentication
					required</preamble>
		  <artwork><![CDATA[ Authentication Required</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (2)             ----------> Cert request goes into queue
                        <---------- CertRep (2) PENDING
CertPoll (2)            ----------> Still pending
                        <---------- CertRep (2) PENDING
CertPoll (2)            ----------> CA issues certificate
                        <---------- CertRep (2) SUCCESS
Client installs certificate
		  ]]></artwork>
</figure>

<figure>
		  <preamble>CA certificate rollover case:</preamble>
		  <artwork><![CDATA[
<name>CA Certificate Rollover Case</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
GetNextCACert         ---------->
                      <---------- New CA certificate

PKCSReq*              ----------> CA issues certificate with
                                  new key
                      <---------- CertRep SUCCESS
Client stores certificate
for installation when
existing certificate expires.
		  ]]></artwork>
		  <postamble>*
</figure>

        <t>* Enveloped for the new CA certificate.  The CA will use
					   the envelope to determine which key to use to issue the
					   client certificate.</postamble>
		</figure> certificate.</t>
      </section>
      <section title="Transactions numbered="true" toc="default">
        <name>Transactions with Errors"> Errors</name>
        <t>

In the case of polled transactions that aren't completed automatically, there
are two potential options for dealing with a transaction that's interrupted
due to network or software/hardware issues.  The first is for the client to
preserve its transaction state and resume the CertPoll polling when normal
service is restored. The second is for the client to begin a new transaction
by sending a new PKCSReq/RenewalReq PKCSReq/RenewalReq, rather than continuing the previous
CertPoll.  Both options have their own advantages and disadvantages.

        </t>
        <t>

The CertPoll continuation requires that the client maintain its transaction
state for the time when it resumes polling.  This is relatively simple if the
problem is a brief network outage, but less simple when the problem is a
client crash and restart.  In addition addition, the CA may treat a lost network
connection as the end of a transaction, so that a new connection followed by a
CertPoll will be treated as an error.

        </t>
        <t>

The PKCSReq/RenewalReq continuation doesn't require any state to be maintained maintained,
since it's a new transaction, however transaction. However, it may cause problems on the CA side if
the certificate was successfully issued but the client never received it,
since the resumed transaction attempt will appear to be a request for a
duplicate certificate (see <xref target="security-no-conf"/> target="security-no-conf" format="default"/> for more on why
this is a problem).  In this case case, the CA may refuse the transaction, transaction or
require manual intervention to remove/revoke the previous certificate before
the client can request another one.

        </t>
        <t>

Since the new-transaction resume is more robust in the presence of errors and
doesn't require special-case handling by either the client or CA, clients
SHOULD
<bcp14>SHOULD</bcp14> use the new-transaction option in preference to the resumed-CertPoll
option to recover from errors.

        </t>

		<figure>
		  <preamble>Resync
        <t>Resync Case 1: Client resyncs via new PKCSReq
					(recommended):</preamble>
		  <artwork><![CDATA[
					(recommended):</t>
<figure>
<name>Resync Case 1</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (3)           ----------> Cert request goes into queue
                      <---------- CertRep (3) PENDING
CertPoll (3)          ----------> Still pending
                        X-------- CertRep(3) PENDING
(Network outage)
(Client reconnects)
PKCSReq (4)           ---------->
                      <---------- CertRep (4) PENDING
etc...
		  ]]></artwork>
</figure>

		<figure>
		  <preamble>Resync

        <t>Resync Case 2: Client resyncs via resumed CertPoll after a
					network outage (not recommended, recommended; use PKCSReq to
					resync):</preamble>
		  <artwork><![CDATA[
					resync):</t>
<figure>
<name>Resync Case 2</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (5)           ----------> Cert request goes into queue
                      <---------- CertRep (5) PENDING
CertPoll (5)          ----------> Still pending
                        X-------- CertRep(5) PENDING
(Network outage)
(Client reconnects)
CertPoll (5)          ----------> CA issues certificate
                      <---------- CertRep (5) SUCCESS
Client installs certificate
		  ]]></artwork>
</figure>

		<figure>
		  <preamble>Resync

        <t>Resync Case 3: Special-case variation of case Case 2 where the
					CertRep SUCCESS rather than the CertRep PENDING is
					lost (recommended):</preamble>
		  <artwork><![CDATA[ (recommended):</t>
<figure>
<name>Resync Case 3</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (6)           ----------> Cert request goes into queue
                      <---------- CertRep (6) PENDING
CertPoll (6)          ----------> Still pending
                      <---------- CertRep (6) PENDING
CertPoll (6)          ----------> CA issues certificate
                        X-------- CertRep(6) SUCCESS
(Network outage)
(Client reconnects)
PKCSReq (7)           ----------> There is already a valid
                                  certificate with this DN.
				  Distinguished Name (DN).
                      <---------- CertRep (7) FAILURE
                                  Admin revokes certificate
PKCSReq (8)           ----------> CA issues new certificate
                      <---------- CertRep (8) SUCCESS
Client installs certificate
		  ]]></artwork>
</figure>

		<figure>
		  <preamble>Resync

        <t>Resync Case 4: Special-case variation of case Case 1 where the
					CertRep SUCCESS rather than the CertRep PENDING is lost
					(not recommended, recommended; use PKCSReq to resync):</preamble>
		  <artwork><![CDATA[ resync):</t>
<figure>
<name>Resync Case 4</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
PKCSReq (9)           ----------> Cert request goes into queue
                      <---------- CertRep (9) PENDING
CertPoll (9)          ----------> Still pending
                      <---------- CertRep (9) PENDING
CertPoll (9)          ----------> CA issues certificate
                        X-------- CertRep(9) SIGNED CERT
(Network outage)
(Client reconnects)
CertPoll (9)          ----------> Certificate already issued
                      <---------- CertRep (9) SUCCESS
Client installs certificate
		  ]]></artwork>
</figure>
        <t>

As these examples indicate, resumption from an error via a resumed CertPoll is
tricky due to the state that needs to be held by both the client and/or the
CA.  A PKCSReq/RenewalReq resume is the easiest to implement implement, since it's
stateless and is identical for both polled and non-polled nonpolled transactions, while whereas
a CertPoll resume treats the two differently (a non-polled differently. (A nonpolled transaction is
resumed with a PKCSReq/RenewalReq, PKCSReq/RenewalReq; a polled transaction is resumed with a
CertPoll).
CertPoll.)  For this reason reason, error recovery SHOULD <bcp14>SHOULD</bcp14> be handled via a new PKCSReq
rather than a resumed CertPoll.

        </t>
      </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"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>

One
A object identifier for an arc to assign SCEP Attribute Identifiers was has been
assigned in the SMI "SMI Security for PKIX (1.3.6.1.5.5.7) registry, PKIX" registry (1.3.6.1.5.5.7).  This object
identifer, Simple Certificate Enrollment Protocol Attributes Attributes, is denoted as
id-scep:
      </t>
	  <figure>
        <artwork><![CDATA[

<sourcecode>
id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 24 }

		]]></artwork>
	  </figure>
	  <t>

(Editor's note: When the OID is assigned, the values in the OID table in <xref
target="pkiMessage"/> will also need to be updated).

	  </t>
</sourcecode>

      <t>

This assignment
IANA created the new SMI "SMI Security for SCEP Attribute Identifiers
((1.3.6.1.5.5.7.TBD1) Identifiers" registry
(1.3.6.1.5.5.7.24) with the following entries with references to
this document:
      </t>
	  <figure>
        <artwork><![CDATA[

<sourcecode>
id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }

		]]></artwork>
	  </figure>
</sourcecode>

    <t>
Entries in the registry are assigned according to the "Specification Required"
policy defined in <xref target="RFC8126"/>. target="RFC8126" format="default"/>.
      </t>
      <t>
<xref target="messageType"/> target="messageType" format="default"/> describes a SCEP an "SCEP Message Type Registry Type" registry, and
<xref target="CA-caps"/> target="CA-caps" format="default"/> describes a SCEP an "SCEP CA Capabilities Registry to be Capabilities"
registry; these registries are maintained by the IANA, defining IANA and define a number of such code point
code-point identifiers. Entries in the registry are to be assigned according
to the "Specification Required" policy defined in <xref target="RFC8126"/>. target="RFC8126" format="default"/>.

      </t>
      <t>
The SCEP "SCEP Message Type Registry Types" registry has columns "Value," "Name," "Description," "Value", "Name", "Description", and
"Reference".
"Reference" columns.  The "Value" entry is a small positive integer, with the integer; value
"0" is reserved.
      </t>
      <t>
The SCEP "SCEP CA Capabilities Registry Capabilities" registry has columns "Keyword", "Description", and
"Reference".
"Reference" columns.  Although implementations SHOULD <bcp14>SHOULD</bcp14> use the SCEP "SCEP CA Capabilities
Registry, Capabilities"
registry, SCEP is often employed in situations where this isn't possible.  In
this case 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
entity that defines the capability.  For example example, the prefix would be
"Example.com-"
"Example.com-", and the complete capability would be
"Example.com-CapabilityName".
      </t>
      <t>

This document defines
IANA has registered four media types for IANA registration: as defined in this document:
      </t>
	  <figure>
        <artwork><![CDATA[

"application/x-x509-ca-cert"
"application/x-x509-ca-ra-cert"
"application/x-x509-next-ca-cert"
"application/x-pki-message"

		]]></artwork>
	  </figure>

<ul>
<li>application/x-x509-ca-cert</li>
<li>application/x-x509-ca-ra-cert</li>
<li>application/x-x509-next-ca-cert</li>
<li>application/x-pki-message</li>
</ul>
      <t>
Note that these are grandfathered media types registered as per Appendix A of <xref target="RFC6838"/>.
target="RFC6838" sectionFormat="of" section="A"/>.  Templates
for registrations are specified below.
      </t>

      <section title="Registration numbered="true" toc="default">
        <name>Registration of the 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</name>
<dl>
<dt>Type name:</dt>
<dd>application</dd>
<dt>Subtype name:</dt>
<dd>x-x509-ca-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 contains a certificate, certificate; see the
Security Considerations section of <xref target="PKIX"/>. target="RFC5280"
format="default"/>. There is no executable content.
		</t>
		<t>
Interoperability considerations:  This content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration of an alias to application/pkix-cert
(basically a single DER encoded DER-encoded Certification Authority certificate), which is
only used in SCEP.
		</t>
		<t>
Published specification: draft-gutmann-scep-15
		</t>
		<t>
Applications SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type: SCEP type:</dt>
<dd>SCEP uses this media type when returning a CA certificate.
		</t>
		<t>
Fragment certificate.</dd>
<dt>Fragment identifier considerations:  N/A
		</t>
		<t>
Additional information:
		</t>
		<t>
Deprecated considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type: N/A
		</t>
		<t>
Magic number(s): none
		</t>
		<t>
File extension(s): N/A
		</t>
		<t>
Macintosh 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): N/A
		</t>
		<t>
Person code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information: See information:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Intended usage: LIMITED USE
		</t>
		<t>
Restrictions RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE</dd>
<dt>Restrictions on usage: SCEP protocol
		</t>
		<t>
Author: See usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Change controller: IETF
		</t>
		<t>
Provisional registration? No

		</t> RFC 8894</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>No</dd>
</dl>
      </section>
      <section title="Registration numbered="true" toc="default">
        <name>Registration of the application/x-x509-ca-ra-cert media type">
		<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</name>

<dl>
<dt>Type name:</dt>
<dd>application</dd>
<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 Signed-Data SignedData message (<xref target="certs-only"/>) target="certs-only"
format="default"/>) containing the certificates, with the intermediate CA
certificate(s) as the leaf certificate(s). There is no executable content.
		</t>
		<t>
Interoperability considerations:  This
content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration which that is only used in SCEP.
		</t>
		<t>
Published specification: draft-gutmann-scep-15
		</t>
		<t>
Applications SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type: SCEP type:</dt>
<dd>SCEP uses this media type when returning CA Certificate Chain Response.
		</t>
		<t>
Fragment
Response.</dd>
<dt>Fragment identifier considerations:  N/A
		</t>
		<t>
Additional information:
		</t>
		<t>
Deprecated considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type: N/A
		</t>
		<t>
Magic number(s): none
		</t>
		<t>
File extension(s): N/A
		</t>
		<t>
Macintosh 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): N/A
		</t>
		<t>
Person code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information:  See information:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Intended usage: LIMITED USE
		</t>
		<t>
Restrictions RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE</dd>
<dt>Restrictions on usage: SCEP protocol
		</t>
		<t>
Author: See usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Change controller: IETF
		</t>
		<t>
Provisional registration?  no

		</t> RFC 8894.</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>no</dd>
</dl>
      </section>

      <section title="Registration numbered="true" toc="default">
        <name>Registration of the application/x-x509-next-ca-cert media type">
		<t>

Type name: application
		</t>
		<t>
Subtype name: x-x509-next-ca-cert
		</t>
		<t>
Required parameters: none
		</t>
		<t>
Optional parameters: none
		</t>
		<t>
Encoding considerations: binary
		</t>
		<t>
Security considerations: This Media Type</name>
<dl>
<dt>Type name:</dt>
<dd>application</dd>
<dt>Subtype name:</dt>
<dd>x-x509-next-ca-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 Signed-Data SignedData CMS message, signed by the
current CA signing key. There is no executable content.
		</t>
		<t>
Interoperability considerations: This content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration which that is only used in SCEP.
		</t>
		<t>
Published specification: draft-gutmann-scep-15
		</t>
		<t>
Applications SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type: SCEP type:</dt>
<dd>SCEP uses this media type when returning a Get Next CA Response.
		</t>
		<t>
Fragment response.</dd>
<dt>Fragment identifier considerations: N/A
		</t>
		<t>
Additional information:
		</t>
		<t>
Deprecated considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type: N/A
		</t>
		<t>
Magic number(s): none
		</t>
		<t>
File extension(s): N/A
		</t>
		<t>
Macintosh 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): N/A
		</t>
		<t>
Person code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information: See information:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Intended usage: LIMITED RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE
		</t>
		<t>
Restrictions </dd>
<dt>Restrictions on usage: SCEP protocol
		</t>
		<t>
Author: See usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Change controller: IETF
		</t>
		<t>
Provisional registration?  no

		</t> RFC 8894.</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>no</dd>
</dl>
      </section>

      <section title="Registration numbered="true" toc="default">
        <name>Registration of the application/x-pki-message media type">
		<t>

Type name: application
		</t>
		<t>
Subtype name: x-pki-message
		</t>
		<t>
Required parameters: none
		</t>
		<t>
Optional parameters: none
		</t>
		<t>
Encoding considerations: binary
		</t>
		<t>
Security considerations: This Media Type</name>
<dl>
<dt>Type name:</dt>
<dd>application</dd>
<dt>Subtype name:</dt>
<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 Signed-Data SignedData
message. There is no executable content.
		</t>
		<t>
Interoperability considerations: This content.</dd>
<dt>Interoperability considerations:</dt>
<dd>This is a grandfathered registration which that is only used in SCEP.
		</t>
		<t>
Published specification: draft-gutmann-scep-15
		</t>
		<t>
Applications SCEP.</dd>
<dt>Published specification:</dt>
<dd>RFC 8894</dd>
<dt>Applications that use this media type: SCEP type:</dt>
<dd>SCEP uses this media type when returning a Certificate Enrolment/Renewal Response.
		</t>
		<t>
Fragment
Response.</dd>
<dt>Fragment identifier considerations:  N/A
		</t>
		<t>
Additional information:
		</t>
		<t>
Deprecated considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd><t><br/></t>
<dl>
<dt>Deprecated alias names for this type: N/A
		</t>
		<t>
Magic number(s): none
		</t>
		<t>
File extension(s): N/A
		</t>
		<t>
Macintosh 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): N/A
		</t>
		<t>
Person code(s):</dt>
<dd>N/A</dd>
</dl>
</dd>
<dt>Person and email address to contact for further information: See information:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Intended usage: LIMITED USE
		</t>
		<t>
Restrictions RFC 8894.</dd>
<dt>Intended usage:</dt>
<dd>LIMITED USE</dd>
<dt>Restrictions on usage: SCEP protocol
		</t>
		<t>
Author: See usage:</dt>
<dd>SCEP protocol</dd>
<dt>Author:</dt>
<dd>See the Authors' Addresses section of draft-gutmann-scep-15
		</t>
		<t>
Change controller: IETF
		</t>
		<t>
Provisional registration?  no

		</t> RFC 8894.</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
<dt>Provisional registration?</dt>
<dd>no</dd>
</dl>
      </section>
    </section>
    <!-- ====================================================================== -->

    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
The security goal of SCEP is that no adversary can subvert the public
key/identity binding from that intended.  An adversary is any entity other
than the client and the CA participating in the protocol.
      </t>
      <t>
This goal is met through the use of CMS and PKCS #10 encryption and digital
signatures using authenticated public keys.  The CA's public key is
authenticated via out-of-band means such as the checking of the CA fingerprint fingerprint,
and the SCEP client's public key is authenticated through manual or pre-shared preshared
secret authentication.
      </t>
      <section title="General Security"> numbered="true" toc="default">
        <name>General Security</name>
        <t>
Common key-management considerations such as keeping private keys truly
private and using adequate lengths for symmetric and asymmetric keys must be
followed in order to maintain the security of this protocol.  This is
especially true for CA keys which, when compromised, compromise the security
of all relying parties.
        </t>
      </section>
      <section title="Use numbered="true" toc="default">
        <name>Use of the CA private key"> Private Key</name>
        <t>
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
or encryption.  The SCEP protocol however protocol, however, uses the CA private key to both sign
and optionally encrypt CMS transport messages.  This is generally considered
undesirable
undesirable, as it widens the possibility of an implementation weakness and
provides an additional location where the private key must be used (and hence
is slightly more vulnerable to exposure) and where a side-channel attack might
be applied.
        </t>
      </section>
      <section title="ChallengePassword numbered="true" toc="default">
        <name>ChallengePassword Shared Secret Value"> Value</name>
        <t>
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,
with SCEP used to provision devices with certificates in the manufacturing
facility, the physical security of the facility may be enough to protect the
certificate issue process with no additional measures explicitly required.  In
general though
general, though, the security of the issue process depends on the security
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
following security measures should be considered.

        <list style="symbols">
          <t>
        </t>

        <ul spacing="compact">
          <li>
The challengePassword, despite its name, shouldn't be a conventional password
but a high-entropy shared secret shared-secret authentication string.  Using the base64
encoding of a keying value generated or exchanged as part of standard device
authentication protocols like EAP the Extensible Authentication Protocol (EAP) or
DNP3 SA Secure Authentication (DNP3-SA) makes for a good
challengePassword.  The use of high-entropy shared secrets is particulary particularly
important when the PasswordRecipientInfo option is used to encrypt SCEP
messages,
messages; see <xref target="message-processing"/>.

          </t>
          <t> target="message-processing" format="default"/>.
          </li>

          <li>
If feasible, the challengePassword should be a one-time value used to
authenticate the issue of a single certificate (subsequent certificate
requests will be authenticated by being signed with the initial certificate).
If the challengePassword is single-use single use, then the arrival of subsequent requests
using the same challengePassword can then be used to indicate a security
breach.

          </t>
          <t>
          </li>

          <li>
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
attacker manages to compromise the challengePassword value, value -- for example example, by
compromising the device that it's stored in.

          </t>
          <t>
          </li>

          <li>
The CA should take appropriate measures to protect the challengePassword, for
example via
challengePassword. Examples of possible measures include: physical security measures, or by
measures; storing it as a salted iterated hash or equivalent memory-hard function or
function; storing it as a keyed MAC value if it's not being used for encryption, or by
encryption; and storing it in encrypted form if it is being used for encryption.

          </t>
        </list>
		</t>
          </li>
        </ul>
      </section>

      <section anchor="security-no-conf" title="Lack numbered="true" toc="default">
        <name>Lack of Certificate Issue Confirmation"> Confirmation</name>
        <t>
SCEP provides no confirmation that the issued certificate was successfully
received and processed by the client.  This means that if the CertRep message
is lost or can't be processed by the client client, then the CA will consider the
certificate successfully issued while the client won't.  If this situation is
of concern concern, then the correct issuance of the certificate will need to be
verified by out-of-band means, for example example, through the client sending a
message signed by the newly-issued newly issued certificate to the CA.  This also provides
the proof of possession that's not present in the case of a renewal operation, operation;
see <xref target="security-no-pop"/>. target="security-no-pop" format="default"/>.
        </t>
      </section>
      <section anchor="security-getcacaps" title="GetCACaps Issues"> numbered="true" toc="default">
        <name>GetCACaps Issues</name>
        <t>
The GetCACaps response is not authenticated by the CA.  This allows an
attacker to perform downgrade attacks on the cryptographic capabilities of the
client/CA exchange.  In particular particular, if the server were to support MD5 and
single DES DES, then an in-path attacker could trivially roll back the encryption
to use these insecure algorithms.  By taking advantage of the presence of
large amounts of static known plaintext in the SCEP messages, as of 2017 2017, a DES
rainbow table attack can recover most encryption keys in under a minute, and
MD5 chosen-prefix collisions can be calculated for a few tens of cents of
computing time using tools like HashClash.  It is for this reason that this
specification makes single DES and MD5 a MUST NOT <bcp14>MUST NOT</bcp14> feature.  Note that all
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
reason to fall all the way back to single DES and MD5. MD5.</t>
      <t>
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
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
either discontinue the exchange or continue as if "SCEPStandard" had been
returned.  This requires a certain tradeoff trade-off between compatibility with old
servers and security against active attacks.
        </t>
      </section>
      <section anchor="security-no-pop" title="Lack numbered="true" toc="default">
        <name>Lack of PoP in Renewal Requests"> Requests</name>
        <t>
Renewal operations (but not standard certificate-issue operations) are
processed via a previously-issued previously issued certificate and its associated private key,
not the key in the PKCS #10 request.  This means that a client no longer
demonstrates proof of possession (PoP) of the private key corresponding to the
public key in the PKCS #10 request.  It is therefore possible for a client to
re-certify
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
signature, an attacker can appear to have a piece of data signed by their
certificate rather than the original signer's certificate.  This, and other,
attacks are described in <xref target="ESS">S/MIME target="RFC2634" format="default">S/MIME ESS</xref>.
        </t>
        <t>
Avoiding these types of attacks requires situation-specific measures.  For
example
example, CMS/SMIME implementations may use the ESSCertID attribute from <xref
target="ESS">S/MIME
target="RFC2634" format="default">S/MIME ESS</xref> or its successor successor, <xref target="ESSv2">S/MIME
ESSv2</xref>
target="RFC5035" format="default">S/MIME
ESSv2</xref>, to unambiguously identify the signing certificate.  However  However, since
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
actual issue with SCEP.
        </t>
      </section>
      <section anchor="traffic-monitoring" title="Traffic Monitoring"> numbered="true" toc="default">
        <name>Traffic Monitoring</name>
        <t>
SCEP messages are signed with certificates that may contain identifying
information.  If these are sent over the public Internet and real identity
information (rather than placeholder values or arbitrary device IDs) are is
included in the signing certificate data, an attacker may be able to monitor
the identities of the entities submitting the certificate requests.  If this
is an issue issue, then <xref target="RFC7258"/> target="RFC7258" format="default"/> should be consulted for guidance.
        </t>
      </section>
      <section anchor="security-unnecessary" title="Unnecessary cryptography"> numbered="true" toc="default">
        <name>Unnecessary Cryptography</name>
        <t>
Some of the SCEP exchanges use unnecessary signing and encryption operations.
In particular particular, the GetCert and GetCRL exchanges are encrypted and signed in
both directions.  The information requested is public public, and thus encrypting the
requests is of questionable value.  In addition addition, CRLs and certificates sent in
responses are already signed by the CA and can be verified by the recipient
without requiring additional signing and encryption.  More lightweight means
of retrieving certificates and CRLs such as <xref target="HTTP-certstore">HTTP target="RFC4387" format="default">HTTP
certificate-store access</xref> and LDAP are recommended for this reason.
        </t>
      </section>
      <section anchor="security-sha1" title="Use numbered="true" toc="default">
        <name>Use of SHA-1"> SHA-1</name>
        <t>
The majority of the large numbers number of devices that use SCEP today default to
SHA-1, with many supporting only that hash algorithm with no ability to
upgrade to a newer one.  SHA-1 is no longer regarded as secure in all
situations, but as used in SCEP SCEP, it's still safe.  There are three reasons for
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
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,
and then creating a second SHA-1 collision for the signature on the encrypted
data), which won't be feasible for a long time.
        </t>
        <t>
The second reason is that the signature over the message, message -- in other words words, the
SHA-1 hash that isn't protected by encryption, encryption -- doesn't serve any critical
cryptographic purpose: The PKCS #10 data itself is authenticated through its
own signature, protected by encryption, and the overall request is authorised
by the (encrypted) shared secret.  The sole exception to this will be the
small number of implementations that support the Renewal operation, which may
be authorised purely through a signature, but presumably any implementation
recent enough to support Renewal also supports SHA-2.  Any legacy
implementation that supports the historic core SCEP protocol would not be
affected.
        </t>
        <t>
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 renewal request that
didn't include a shared secret (in other words words, one that was only authorised
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
returned certificate, which is protected with the same key that was used to
generate the signature.  While <xref target="security-unnecessary"/> target="security-unnecessary" format="default"/> points
out that SCEP uses unnecessary cryptography in places, the additional level of
security provided by the extra crypto makes it immune to any issues with
SHA-1.
        </t>
        <t>
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.
        </t>
      </section>
    </section>
    <!-- ====================================================================== -->

  </middle>
  <!-- ======================================================================== -->
  <back>

    <references title="Normative References">

      <reference anchor='RFC2119'>
        <front>
          <title abbrev='RFC Key Words'>Key words for use in RFCs

      <section title="Use of HTTP">
              <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 Indicate Requirement 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/rfc2119.html' />
        <format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
      </reference>

      <reference anchor='RFC6838'>
        <front>
          <title>Media Type Specifications the more complex configuration, 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
potential security vulnerability may result due to the addition of 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'>
        <front>
          <title>Guidelines 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 Writing an IANA Considerations Section both TLS and SCEP often leads to
interoperability problems because different certificates and trust models are
used 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'>
        <front>
          <title>Ambiguity each.  Use of HTTPS to authenticate the server does not enable
omission of Uppercase vs Lowercase the ChallengePassword or similar authenticator in RFC 2119 Key Words</title>
          <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'>
        <front>
          <title>Augmented BNF 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 Syntax Specifications: ABNF</title>
          <author initials="R" surname="Crocker"></author>
          <author initials="P" surname="Overell"></author>
          <date year='2008' month='January' />
        </front>
        <seriesInfo name='RFC' value='5234' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc5234.txt' />
      </reference> security and is
unnecessary for SCEP, which uses cryptographically secured messages and does
not require transport layer security.
	  </t>
    </section>
  </section>

      </middle>

  <back>
<displayreference target="I-D.ietf-httpbis-bcp56bis" to="HTTP" />

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>

        <reference anchor="AES">
          <front>
            <title>The Advanced Encryption Standard (AES)</title>
            <seriesInfo name="FIPS" value="197"/>
            <author fullname='U.S. fullname="U.S. National Institute of Standards and Technology'> Technology">
              <organization>NIST</organization>
            </author>
            <date year='2001' month='November' /> year="2001" month="November"/>
          </front>
<seriesInfo name='FIPS' value='197' name="DOI" value="10.6028/NIST.FIPS.197" />
        </reference>

        <reference anchor="SHA2">
          <front>
            <title>Secure Hash Standard (SHS)</title>
          <author fullname='U.S. National Institute of Standards and Technology'>
              <organization>NIST</organization>
          </author>
          <date year='2008' month='October' />
        </front>
        <seriesInfo name='FIPS' value='180-3' />
      </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 Routing</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'>
        <front>
          <title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
          <author initials="M" surname="Nystrom"></author>
          <author initials="B" surname="Kaliski"></author>
          <date year='2000' month='November' />
        </front>
        <seriesInfo name='RFC' value='2985' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc2985.txt' />
      </reference>

      <reference anchor='PKCS10'>
        <front>
          <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'>
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate 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'>
        <front>
          <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
          <author initials="T" surname="Berners-Lee"></author>
          <author initials="R" surname="Fielding"></author>
          <author initials="L" surname="Masinter"></author>
          <date year='2005' month='January' />
        </front>
        <seriesInfo name='RFC' value='3986' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc3986.txt' />
      </reference>

    </references>
    <references title="Informative References">

      <reference anchor='BCP56bis'>
        <front>
          <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-httpbis-bcp56bis-08' />
      </reference>

      <reference anchor='HTTP-certstore'>
        <front>
          <title>Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP</title> (SHS)</title>
            <seriesInfo name="FIPS" value="180-3"/>
            <author initials="P" surname="Gutmann"></author> fullname="U.S. National Institute of Standards and Technology">
              <organization>NIST</organization>
            </author>
            <date year='2006' month='February' /> year="2008" month="October"/>
          </front>
        <seriesInfo name='RFC' value='4387' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc4387.txt' />
        </reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-httpbis-bcp56bis.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4387.xml"/>

        <reference anchor="JSCEP" target="https://github.com/jscep/jscep">
          <front>
            <title>A Java implementation of the Simple Certificate Enrolment Protocol</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 Algorithm 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' /> month="January" year="2020"/>
          </front>
	  <seriesInfo name='RFC' value='8446' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc8446.txt' name="commit" value="7410332" />
        </reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2634.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      </references>
    </references>
    <!-- ====================================================================== -->

    <section anchor="background" title="Background Notes"> numbered="true" toc="default">
      <name>Background Notes</name>
      <t>

This specification has spent over twenty years in the draft stage.  Its
original goal, provisioning IPsec routers with certificates, has long since
changed to general device/embedded system/IoT use.  To fit this role, extra
features were bolted on in a haphazard manner through the addition of a
growing list of appendices and by inserting additional, often conflicting,
paragraphs in various locations in the body text.  Since existing features
were never updated as newer ones were added, the specification accumulated
large amounts of historical baggage over time.  If OpenPGP was described as "a
museum of 1990s crypto" crypto", then the SCEP draft document was its graveyard.

      </t>
      <t>

About five years ago ago, the specification, which even at that point had seen only
sporadic re-posts reposts of the existing document, was more or less abandoned by its
original sponsors.  Due to its widespread use in large segments of the
industry, the specification was rebooted in 2015, cleaning up fifteen years years'
worth of accumulated cruft, fixing errors, clarifying ambiguities, and
bringing the algorithms and standards used into the current century (prior to
the update, the de-facto lowest-common denominator de facto lowest-common-denominator algorithms used for
interoperability were the insecure forty-year-old single DES and broken MD5
hash algorithms).

      </t>
      <t>

Note that although the text of the current specification has changed
significantly due to the consolidation of features and appendices into the
main document, the protocol that it describes is identical on the wire to the
original (with the unavoidable exception of the switch from single DES and MD5
to AES and SHA-2).  The only two changes introduced, the "SCEPStandard"
indicator in GetCACaps and the failInfoText attribute, are both optional
values and would be ignored by older implementations that don't support them,
or can be omitted from messages if they are found to cause problems.

      </t>
      <t>

Other changes include:

      </t>
      <t>

      <list style="symbols">

		<t>Resolved
      <ul>
        <li>Resolved contradictions in the text, text -- for example example, a requirement
	given as a MUST <bcp14>MUST</bcp14> in one paragraph and a SHOULD
	<bcp14>SHOULD</bcp14> in the next, a MUST NOT <bcp14>MUST NOT</bcp14>
	in one paragraph and a MAY <bcp14>MAY</bcp14> a few paragraphs later, a SHOULD NOT
	<bcp14>SHOULD NOT</bcp14> contradicted later by a MAY, <bcp14>MAY</bcp14>, and so on.</t>

		<t>Merged on.</li>
        <li>Merged several later fragmentary addenda placed in appendices (for
		example
	example, the handling of certificate renewal) with the body of the
		text.</t>

		<t>Merged
	text.</li>
        <li>Merged the SCEP Transactions "SCEP Transactions" and SCEP Transport "SCEP Transport" sections, since the
		latter mostly duplicated (with occasional inconsistencies) the
		former.</t>

		<t>Updated
		former.</li>
        <li>Updated the algorithms to ones dating from at least this
		century.</t>

		<t>Did
		century.</li>
        <li>Did the same for normative references to other standards.</t>

		<t>Updated standards.</li>
        <li>Updated the text to use consistent terminology for the client and
		CA rather than a mixture of client, requester, requesting system, end
		entity, server, certificate authority, certification authority, and
		CA.</t>

		<t>Corrected
		CA.</li>
        <li>Corrected incorrect references to other standards, e.g. e.g.,
		IssuerAndSerial -> IssuerAndSerialNumber.</t>

		<t>Corrected -&gt; IssuerAndSerialNumber.</li>
        <li>Corrected errors such as a statement that when both signature and
		encryption certificates existed, the signature certificate was used
		for encryption.</t>

		<t>Condensed encryption.</li>
        <li>Condensed redundant discussions of the same topic spread across
		multiple sections into a single location.  For example example, the description
		of intermediate CA handling previously existed in three different
		locations, with slightly different reqirements requirements in each one.</t>

		<t>Added one.</li>
        <li>Added a description of how pkiMessages were processed, which was
		never made explicit in the original specification.  This led to
		creative interpretations that had security problems but were employed
		anyway due to the lack of specific guidance on what to do.</t>

		<t>Relaxed do.</li>
        <li>Relaxed some requirements that didn't serve any obvious purpose and
		that major implementations didn't seem to be enforcing.  For example example,
		the requirement that the self-signed certificate used with a request
		MUST
		<bcp14>MUST</bcp14> contain a subject name that matched the one in the PKCS #10
		request was relaxed to a SHOULD <bcp14>SHOULD</bcp14>, because a number of implementations
		either ignored the issue entirely or at worst performed some minor
		action like creating a log entry entry, after which they continued
		anyway.</t>

		<t>Removed
		anyway.</li>
        <li>Removed discussion of the transactionID from the security
		considerations, since the instructions there were directly
		contradicted by the discussion of the use of the transactionID in
		<xref target="state-trans"/>.</t>

		<t>Added target="state-trans" format="default"/>.</li>
        <li>Added a requirement that the signed message include the signing
		certificate(s) in the signedData certificates field.  This was
		implicit in the original specification (without it, the message
		couldn't be verified by the CA) and was handled by the fact that most
		PKCS #7/CMS libraries do this by default, but was never explicitly
		mentioned.</t>

		<t>Clarified
		mentioned.</li>
        <li>Clarified sections that were unclear or even made no sense, sense -- for
		example
		example, the requirement for a "hash on the public key" [sic] encoded
		as a PrintableString.</t>

		<t>Renamed PrintableString.</li>
        <li>Renamed "RA certificates" to "intermediate CA certificates".  The
		original document at some point added mention of RA certificates
		without specifying how the client was to determine that an RA was in
		use, how the RA operations were identified in the protocol, or how it
		was used.  It's unclear whether what was meant was a true RA or merely
		an intermediate CA, as opposed to the default practice of having
		certificates issued directly from a single root CA certificate.  This
		update uses the term "intermediate CA certificates", since this seems
		to have been the original intent of the text.</t>

		<t>Redid text.</li>
        <li>Redid the PKIMessage diagram to match what was specified in CMS, CMS;
		the original diagram omitted a number of fields and nested data
		structures
		structures, which meant that the diagram didn't match either the text
		or the CMS specification.</t>

		<t>Removed specification.</li>
        <li>Removed the requirement for a CertPoll to contain a recipientNonce,
		since CertPoll is a client message and will never be sent in response
		to a message containing a senderNonce.  See also the note in
		<xref target="CertRep"/>.</t>

		<t>Clarified target="CertRep" format="default"/>.</li>
        <li>Clarified certificate renewal.  This represents a capability that
		was bolted onto the original protocol with (at best) vaguely-defined vaguely defined
		semantics, including a requirement by the CA to guess whether a
		particular request was a renewal or not.  In response to developer
		feedback that they either avoided renewal entirely because of this
		uncertainty or hardcoded hard-coded in particular behaviour on a per-CA basis,
		this specification explicitly identifies renewal requests as such, such and
		provides proper semantics for them.</t>

		<t>Corrected them.</li>
        <li>Corrected the requirement that "undefined message types are treated
		as an error" error", since this negates the effect of GetCACaps, which is used
		to define new message types.  In particular particular, operations such as
		GetCACaps "Renewal" would be impossible if enforced as written,
		because the Renewal operation was an undefined message type at the
		time.</t>

		<t>In
		time.</li>
        <li>In line with the above, added IANA registries for several entries
		that had previously been defined in an ad-hoc ad hoc manner in different
		locations in the text.</t>

		<t>Added text.</li>
        <li>Added the "SCEPStandard" keyword to GetCACaps to indicate that the
		CA complies with the final version of the SCEP standard, since the
		definition of what constitutes SCEP standards compliance has changed
		significantly over the years.</t>

		<t>Added years.</li>
        <li>Added the optional failInfoText attribute to deal with the fact
		that failInfo was incapable of adequately communicating to clients why
		a certificate request operation had been rejected.</t>

		<t>Removed rejected.</li>
        <li>Removed the discussion in the security considerations of revocation
		issues, since SCEP doesn't support revocation as part of the
		protocol.</t>

		<t>Clarified
		protocol.</li>
        <li>Clarified the use of nonces, which if applied as originally
		specified would have made the use of polling in the presence of a lost
		message impossible.</t>

		<t>Removed impossible.</li>
        <li>Removed the discussion of generating a given transactionID by
		hashing the public key, since this implied that there was some special
		significance in the value generated this way.  Since it was neither a
		MUST
		<bcp14>MUST</bcp14> nor a MAY, <bcp14>MAY</bcp14>, it was unsound
		to imply that servers could rely on the
		value being generated a certain way.  In addition addition, it wouldn't work if
		multiple transactions as discussed in <xref target="poll-resp"/> target="poll-resp"
		format="default"/> were
		initiated, since the deterministic generation via hashing would lead
		to duplicate transactionIDs.</t>

		<t>Added transactionIDs.</li>
        <li>Added examples of SCEP messages to give implementers something to
		aim for.</t>

      </list> for.</li>
      </ul>
    </section>

    <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 their contributions to
early versions of this protocol and this document.
      </t>
    </section>
    <!-- ====================================================================== -->

  </back>
</rfc>