Difference between revisions of "RFC8894"

Latest revision as of 11:22, 30 October 2020

Internet Engineering Task Force (IETF) P. Gutmann Request for Comments: 8894 University of Auckland Category: Informational September 2020 ISSN: 2070-1721

             Simple Certificate Enrolment Protocol

Abstract

This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using 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.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8894.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. Introduction

 1.1.  Conventions Used in This Document

2. SCEP Overview

 2.1.  SCEP Entities
   2.1.1.  Client
   2.1.2.  Certificate Authority
 2.2.  CA Certificate Distribution
 2.3.  Client Authentication
 2.4.  Enrolment Authorisation
 2.5.  Certificate Enrolment/Renewal
   2.5.1.  Client State Transitions
 2.6.  Certificate Access
 2.7.  CRL Access
 2.8.  Certificate Revocation
 2.9.  Mandatory-to-Implement Functionality

3. SCEP Secure Message Objects

 3.1.  SCEP Message Object Processing
 3.2.  SCEP pkiMessage
   3.2.1.  Signed Transaction Attributes
     3.2.1.1.  transactionID
     3.2.1.2.  messageType
     3.2.1.3.  pkiStatus
     3.2.1.4.  failInfo and failInfoText
     3.2.1.5.  senderNonce and recipientNonce
   3.2.2.  SCEP pkcsPKIEnvelope
 3.3.  SCEP pkiMessage types
   3.3.1.  PKCSReq/RenewalReq
   3.3.2.  CertRep
     3.3.2.1.  CertRep SUCCESS
     3.3.2.2.  CertRep FAILURE
     3.3.2.3.  CertRep PENDING
   3.3.3.  CertPoll (GetCertInitial)
   3.3.4.  GetCert and GetCRL
 3.4.  Degenerate certificates-only CMS SignedData
 3.5.  CA Capabilities
   3.5.1.  GetCACaps HTTP Message Format
   3.5.2.  CA Capabilities Response Format

4. SCEP Transactions

 4.1.  HTTP POST and GET Message Formats
 4.2.  Get CA Certificate
   4.2.1.  Get CA Certificate Response Message Format
     4.2.1.1.  CA Certificate Response Message Format
     4.2.1.2.  CA Certificate Chain Response Message Format
 4.3.  Certificate Enrolment/Renewal
   4.3.1.  Certificate Enrolment/Renewal Response Message
 4.4.  Poll for Client Initial Certificate
   4.4.1.  Polling Response Message Format
 4.5.  Certificate Access
   4.5.1.  Certificate Access Response Message Format
 4.6.  CRL Access
   4.6.1.  CRL Access Response Message Format
 4.7.  Get Next Certificate Authority Certificate
   4.7.1.  Get Next CA Response Message Format

5. SCEP Transaction Examples

 5.1.  Successful Transactions
 5.2.  Transactions with Errors

6. IANA Considerations

 6.1.  Registration of the application/x-x509-ca-cert Media Type
 6.2.  Registration of the application/x-x509-ca-ra-cert Media
       Type
 6.3.  Registration of the application/x-x509-next-ca-cert Media
       Type
 6.4.  Registration of the application/x-pki-message Media Type

7. Security Considerations

 7.1.  General Security
 7.2.  Use of the CA Private Key
 7.3.  ChallengePassword Shared Secret Value
 7.4.  Lack of Certificate Issue Confirmation
 7.5.  GetCACaps Issues
 7.6.  Lack of PoP in Renewal Requests
 7.7.  Traffic Monitoring
 7.8.  Unnecessary Cryptography
 7.9.  Use of SHA-1
 7.10. Use of HTTP

8. References

 8.1.  Normative References
 8.2.  Informative References

Appendix A. Background Notes Acknowledgements Author's Address

1 Introduction
- 1.1 Conventions Used in This Document
2 SCEP Overview
3 SCEP Secure Message Objects
4 SCEP Transactions
5 SCEP Transaction Examples
- 5.1 Successful Transactions
- 5.2 Transactions with Errors
6 IANA Considerations
7 Security Considerations
8 References
- 8.1 Normative References
- 8.2 Informative References

Introduction

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

The SCEP protocol supports the following general operations:

CA public key distribution
Certificate enrolment and issue
Certificate renewal
Certificate query
CRL query

SCEP makes extensive use of CMS RFC5652 and PKCS #10 RFC2986.

Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.

This document uses the Augmented Backus-Naur Form (ABNF) notation as specified in RFC5234 for defining formal syntax of commands. Non- terminals not defined in RFC5234 are defined in Section 4.1.

SCEP Overview

This section provides an overview of the functionality of SCEP.

SCEP Entities

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.

Client

A client MUST have the following information locally configured:

1. The CA's fully qualified domain name or IP address.

2. Any identification and/or authorisation information required by

   the CA before a certificate will be issued, as described in
   Section 3.3.1.

3. The identifying information that is used for authentication of

   the CA in Section 4.2.1, typically a certificate fingerprint.

Certificate Authority

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.

Since the client is expected to perform signature verification and optionally encryption using the CA certificate, the keyUsage extension in the CA certificate MUST indicate that it is valid for digitalSignature and keyEncipherment (if the key is to be used for en/decryption) alongside the usual CA usages of keyCertSign and/or cRLSign.

CA Certificate Distribution

If the CA certificate(s) have not previously been acquired by the client through some other means, the client MUST retrieve them before any PKI operation (Section 3) 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.

If an intermediate CA is in use, a certificates-only CMS SignedData message with a certificate chain consisting of all CA certificates is returned. Otherwise, the CA certificate itself is returned.

The CA certificate MAY be provided out of band to the client. Alternatively, the CA certificate fingerprint MAY be used to authenticate a CA certificate distributed by the GetCACert response (Section 4.2) or via HTTP certificate-store access RFC4387. The fingerprint is created by calculating a SHA-256 hash over the whole CA certificate. (For legacy reasons, a SHA-1 hash may be used by some implementations.)

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

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

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 that will be valid in the future once the current certificate has expired. This is done via the GetNextCACert message (Section 4.7).

Client Authentication

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 Section 3, which specifies how CMS is used to encrypt and sign the data. In order to perform the signing operation, the client uses an appropriate local certificate:

1. If the client does not have an appropriate existing certificate,

   then a locally generated self-signed certificate MUST be used.
   The keyUsage extension in the certificate MUST indicate that it
   is valid for digitalSignature and keyEncipherment (if available).
   The self-signed certificate SHOULD use the same subject name and
   key as in the PKCS #10 request.  In this case, the messageType is
   PKCSReq (see Section 3.2.1.2).

2. If the client already has a certificate issued by the SCEP CA,

   and the CA supports renewal (see Section 2.5), that certificate
   SHOULD be used.  In this case, the messageType is RenewalReq (see
   Section 3.2.1.2).

3. Alternatively, if the client has no certificate issued by the

   SCEP CA but has credentials from an alternate CA, then the
   certificate issued by the alternate CA MAY be used in a renewal
   request as described above.  The SCEP CA's policy will determine
   whether the request can be accepted or not.

Note that although the above text describes several different types of operations, for historical reasons, most implementations always apply the first one, even if an existing certificate already exists. For this reason, support for the first case is mandatory while support for the latter ones are optional (see Section 2.9).

During the certificate-enrolment process, the client MUST use the selected certificate's key when signing the CMS envelope (see Section 3). 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 it MUST be included in the signedData certificates field (possibly as part of a full certificate chain). If the key being certified allows encryption, then the CA's CertResp will use the same certificate's public key when encrypting the response.

Note that, in the case of renewal operations, this means that the request will be signed and authenticated with the key in the previously issued certificate rather than the key in the PKCS #10 request, and the response may similarly be returned encrypted with the key in the previously issued certificate. This has security implications; see Section 7.6.

Enrolment Authorisation

PKCS #10 RFC2986 specifies a PKCS #9 RFC2985 challengePassword attribute to be sent as part of the enrolment request. When utilising the challengePassword, the CA distributes a shared secret to the client, which will be used to authenticate the request from the client. It is RECOMMENDED 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 and reuse it to request further certificates.

Inclusion of the challengePassword by the SCEP client is RECOMMENDED; 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; see below). Inclusion is OPTIONAL for renewal requests that are authenticated by being signed with an existing certificate. The CMS envelope protects the privacy of the challengePassword.

A client that is performing certificate renewal as per Section 2.5 SHOULD omit the challengePassword but MAY send the originally distributed shared secret in the challengePassword attribute. The SCEP CA MAY authenticate the request using the challengePassword in addition to the previously issued certificate that signs the request. The SCEP CA MUST NOT attempt to authenticate a client based on a self-signed certificate unless it has been verified through out-of- band means such as a certificate fingerprint.

To perform the authorisation in manual 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 either reject unauthorised requests or mark them for manual authorisation according to CA policy.

Certificate Enrolment/Renewal

A client starts an enrolment transaction (Section 3.3.1) by creating a certificate request using PKCS #10 and sends the request to the CA enveloped using CMS (Section 3).

If the CA supports certificate renewal and the CA policy permits, then a new certificate with new validity dates can be issued, even though the old one is still valid. To renew an existing certificate, the client uses the RenewalReq message (see Section 3.3) and signs it with the existing client certificate. The client SHOULD use a new keypair when requesting a new certificate but MAY request a new certificate using the old keypair.

If the CA returns a CertRep message (Section 3.3.2) with status set to PENDING, the client enters into polling mode by periodically sending a CertPoll message (Section 3.3.3) 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 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 operation requires manual approval.

If polling mode is being used, then the client will send a single PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more CertPoll messages (Section 3.3.3). The CA will, in return, send 0 or more CertRep messages (Section 3.3.2) with status set to PENDING in response to CertPolls, followed by a single CertRep message (Section 3.3.2) with status set to either SUCCESS or FAILURE.

Client State Transitions

The client state transitions during the SCEP process are indicated in Figure 1.

                               CertPoll
                             +-----<----+
                             |          |
                             |          | CertRep(PENDING)
                             |          |

[CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] --------> [CERT-ISSUED]

     ^            PKCSReq    |           CertRep(SUCCESS)
     |          RenewalReq   |
     |                       |
     +-----------------------+
     CertRep(FAILURE) or
     Max-time/max-polls exceeded

                 Figure 1: State Transition Diagram

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

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

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

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

Figure 2 shows a successful transaction in automatic mode

   CLIENT                              CA SERVER

PKCSReq: PKI cert. enrolment message

> CertRep: pkiStatus = SUCCESS

                                 Certificate attached
                                 <------------------------------

Receive issued certificate.

                      Figure 2: Automatic Mode

Figure 3 shows a successful transaction in manual mode:

   CLIENT                              CA SERVER

PKCSReq: PKI cert. enrolment message

> CertRep: pkiStatus = PENDING

                                 <------------------------------

CertPoll: Polling message

> CertRep: pkiStatus = PENDING

                                 <------------------------------

CertPoll: Polling message

> CertRep: pkiStatus = SUCCESS

                                 Certificate attached
                                 <------------------------------

Receive issued certificate.

                       Figure 3: Manual Mode

Certificate Access

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

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 (Section 3.3.4) message and one CertRep (Section 3.3.2) message, as shown in Figure 4.

  CLIENT                               CA SERVER

GetCert: PKI certificate query message

> CertRep: pkiStatus = SUCCESS

                                Certificate attached
                                <-----------------------------

Receive the certificate.

                 Figure 4: Retrieving a Certificate

CRL Access

SCEP clients MAY request a CRL via one of three methods:

1. If the CA supports the CRL Distribution Points (CRLDPs) extension

   RFC5280 in issued certificates, then the CRL MAY be retrieved
   via the mechanism specified in the CRLDP.

2. If the CA supports HTTP certificate-store access RFC4387, then

   the CRL MAY be retrieved via the AuthorityInfoAcces RFC5280
   location specified in the certificate.

3. Only if the CA does not support 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.

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 SignedData message (Section 3.4), as shown in Figure 5.

      CLIENT                           CA SERVER

  GetCRL: PKI CRL query message

>

                                 CertRep: CRL attached
                                 <-----------------------------

Receive the CRL

                     Figure 5: Retrieving a CRL

Certificate Revocation

SCEP does not specify a method to request certificate revocation. In order to revoke a certificate, the client must contact the CA using a non-SCEP-defined mechanism.

Mandatory-to-Implement Functionality

At a minimum, all SCEP implementations compliant with this specification MUST support GetCACaps (Section 3.5.1), GetCACert (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response messages), communication of binary data via HTTP POST (Section 4.1), and the AES128-CBC [AES] and SHA-256 [SHA2] algorithms to secure pkiMessages (Section 3.2).

For historical reasons, implementations MAY support communications of binary data via HTTP GET (Section 4.1), and the triple DES-CBC and SHA-1 algorithms to secure pkiMessages (Section 3.2). Implementations MUST NOT support the obsolete and/or insecure single DES and MD5 algorithms used in earlier versions of this specification, since the unsecured nature of GetCACaps means that an in-path attacker can trivially roll back the encryption used to these insecure algorithms; see Section 7.5.

SCEP Secure Message Objects

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 Figure 6. 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.

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
     }
   }
 }

                       Figure 6: CMS Layering

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 (Section 3.2.2).

The remainder of this document will refer only to "messageData", but it is understood to always be encapsulated in the pkcsPKIEnvelope (Section 3.2.2). The format of the data in the messageData is defined by the messageType attribute (see Section 3.2) of the SignedData. If there is no messageData to be transmitted, the entire pkcsPKIEnvelope MUST be omitted.

Samples of SCEP messages are available through the JSCEP project [JSCEP] in the src/samples directory.

SCEP Message Object Processing

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

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

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

Note that some early implementations of this specification dealt with keys that were not encryption capable by omitting the encryption stage, based on the text in Section 3 that indicated that "the EnvelopedData is omitted". This alternative processing mechanism SHOULD NOT be used since it exposes in cleartext the challengePassword used to authorise the certificate issue.

SCEP pkiMessage

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

The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7

  1}).

The signed content, if present (FAILURE and PENDING CertRep

  messages will lack any signed content), MUST be a pkcsPKIEnvelope
  (Section 3.2.2) and MUST match the messageType attribute.

The SignerInfo MUST contain a set of authenticatedAttributes

  (Section 3.2.1).

Signed Transaction Attributes

At a minimum, all messages MUST contain the following authenticatedAttributes:

A transactionID attribute (see Section 3.2.1.1).
A messageType attribute (see Section 3.2.1.2).
A fresh senderNonce attribute (see Section 3.2.1.5). However,

  note the comment about senderNonces and polling in Section 3.3.2

Any attributes required by CMS.

If the message is a CertRep, it MUST also include the following authenticatedAttributes:

A pkiStatus attribute (see Section 3.2.1.3).
failInfo and optional failInfoText attributes (see

  Section 3.2.1.4) if pkiStatus = FAILURE.

A recipientNonce attribute (see Section 3.2.1.5) copied from the

  senderNonce in the request that this is a response to.

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

                     Table 1: SCEP Attributes

The OIDs used for these attributes are as follows:

+======================+===============================+ | Name | ASN.1 Definition | +======================+===============================+ | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 | | | US(840) 1 VeriSign(113733)} | +----------------------+-------------------------------+ | id-pki | OBJECT_IDENTIFIER ::= {id- | | | VeriSign pki(1)} | +----------------------+-------------------------------+ | id-attributes | OBJECT_IDENTIFIER ::= {id-pki | | | attributes(9)} | +----------------------+-------------------------------+ | id-transactionID | OBJECT_IDENTIFIER ::= {id- | | | attributes transactionID(7)} | +----------------------+-------------------------------+ | id-messageType | OBJECT_IDENTIFIER ::= {id- | | | attributes messageType(2)} | +----------------------+-------------------------------+ | id-pkiStatus | OBJECT_IDENTIFIER ::= {id- | | | attributes pkiStatus(3)} | +----------------------+-------------------------------+ | id-failInfo | OBJECT_IDENTIFIER ::= {id- | | | attributes failInfo(4)} | +----------------------+-------------------------------+ | id-senderNonce | OBJECT_IDENTIFIER ::= {id- | | | attributes senderNonce(5)} | +----------------------+-------------------------------+ | id-recipientNonce | OBJECT_IDENTIFIER ::= {id- | | | attributes recipientNonce(6)} | +----------------------+-------------------------------+ | id-scep | OBJECT IDENTIFIER ::= {id- | | | pkix 24} | +----------------------+-------------------------------+ | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id- | | | scep 1} | +----------------------+-------------------------------+

             Table 2: SCEP Attribute OIDs

The attributes are detailed in the following sections.

transactionID

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

Note that the transactionID must be unique, but not necessarily randomly generated. For example, it may be a value assigned by the CA to allow the client to be identified by their transactionID, using a value such as the client device's 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 preassigned Distinguished Name through which the CA can identify their request -- for example, when enrolling Supervisory Control and Data Acquisition (SCADA) devices.

messageType

The messageType attribute specifies the type of operation performed by the transaction. This attribute MUST be included in all PKI messages. The following message types are defined:

+=======+============+============================================+
| Value | Name       | Description                                |
+=======+============+============================================+
| 0     | Reserved   |                                            |
+-------+------------+--------------------------------------------+
| 3     | CertRep    | Response to certificate or CRL request.    |
+-------+------------+--------------------------------------------+
| 17    | RenewalReq | PKCS #10 certificate request authenticated |
|       |            | with an existing certificate.              |
+-------+------------+--------------------------------------------+
| 19    | PKCSReq    | PKCS #10 certificate request authenticated |
|       |            | with a shared secret.                      |
+-------+------------+--------------------------------------------+
| 20    | CertPoll   | Certificate polling in manual enrolment.   |
+-------+------------+--------------------------------------------+
| 21    | GetCert    | Retrieve a certificate.                    |
+-------+------------+--------------------------------------------+
| 22    | GetCRL     | Retrieve a CRL.                            |
+-------+------------+--------------------------------------------+

                    Table 3: SCEP Message Types

Message types not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).

pkiStatus

All response messages MUST include transaction status information, which is defined as a pkiStatus attribute:

   +=======+=========+========================================+
   | Value | Name    | Description                            |
   +=======+=========+========================================+
   | 0     | SUCCESS | Request granted.                       |
   +-------+---------+----------------------------------------+
   | 2     | FAILURE | Request rejected.  In this case, the   |
   |       |         | failInfo attribute, as defined in      |
   |       |         | Section 3.2.1.4, MUST also be present. |
   +-------+---------+----------------------------------------+
   | 3     | PENDING | Request pending for manual approval.   |
   +-------+---------+----------------------------------------+

                  Table 4: pkiStatus Attributes

PKI status values not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).

failInfo and failInfoText

The failInfo attribute MUST contain one of the following failure reasons:

  +=======+=================+==================================+
  | Value | Name            | Description                      |
  +=======+=================+==================================+
  | 0     | badAlg          | Unrecognised or unsupported      |
  |       |                 | algorithm.                       |
  +-------+-----------------+----------------------------------+
  | 1     | badMessageCheck | Integrity check (meaning         |
  |       |                 | signature verification of the    |
  |       |                 | CMS message) failed.             |
  +-------+-----------------+----------------------------------+
  | 2     | badRequest      | Transaction not permitted or     |
  |       |                 | supported.                       |
  +-------+-----------------+----------------------------------+
  | 3     | badTime         | 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.   |
  +-------+-----------------+----------------------------------+
  | 4     | badCertId       | No certificate could be          |
  |       |                 | identified matching the provided |
  |       |                 | criteria.                        |
  +-------+-----------------+----------------------------------+

                   Table 5: failInfo Attributes

Failure reasons not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).

The failInfoText is a free-form UTF-8 text string that provides further information in the case of pkiStatus = FAILURE. In particular, it may be used to provide details on why a certificate request was not granted that go beyond what's provided by the near- universal failInfo = badRequest status. Since this is a free-form text string intended for interpretation by humans, implementations SHOULD NOT assume that it has any type of machine-processable content.

senderNonce and recipientNonce

The senderNonce and recipientNonce attributes are each a 16-byte random number generated for each transaction. These are intended to prevent replay attacks.

When a sender sends a PKI message to a recipient, a fresh senderNonce MUST be included in the message. The recipient MUST copy the senderNonce into the recipientNonce of the reply as a proof of liveliness. The original sender MUST verify that the recipientNonce of the reply matches the senderNonce it sent in the request. If the nonce does not match, then the message MUST be rejected.

Note that since SCEP exchanges consist of a single request followed by a single response, the use of distinct sender and recipient nonces is redundant, since the client sends a nonce in its request and the CA responds with the same nonce in its reply. In effect, there's just a single nonce, identified as senderNonce in the client's request and recipientNonce in the CA's reply.

SCEP pkcsPKIEnvelope

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

contentType in encryptedContentInfo MUST be data ({pkcs-7 1}).
encryptedContent MUST be the SCEP message being transported (see

  Section 4) and MUST match the messageType authenticated Attribute
  in the pkiMessage.

SCEP pkiMessage types

All of the messages in this section are pkiMessages (Section 3.2), where the type of the message MUST be specified in the "messageType" authenticated Attribute. Each section defines a valid message type, the corresponding messageData formats, and mandatory authenticated attributes for that type.

PKCSReq/RenewalReq

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

The subject Distinguished Name.
The subject public key.
For a PKCSReq, if authorisation based on a shared secret is being

  used, a challengePassword attribute.

In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.

CertRep

The messageData for this type consists of a degenerate certificates- only CMS SignedData message (Section 3.4). 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 3.3.2.1 and 4. In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.

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

CertRep SUCCESS

When the pkiStatus attribute is set to SUCCESS, the messageData for this message consists of a degenerate certificates-only CMS SignedData message (Section 3.4). The content of this degenerate certificates-only SignedData message depends on what the original request was, as outlined in Table 6.

               Table 6: CertRep Response Types

CertRep FAILURE

When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a failInfo (Section 3.2.1.4) attribute set to the appropriate error condition describing the failure. The reply MAY also contain a failInfoText attribute providing extended details on why the operation failed, typically to expand on the catchall failInfo = badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be omitted.

CertRep PENDING

When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (Section 3.2.2) MUST be omitted.

CertPoll (GetCertInitial)

This message is used for certificate polling. For unknown reasons, it was referred to as "GetCertInitial" in earlier draft versions of this specification. The messageData for this type consists of an IssuerAndSubject:

issuerAndSubject ::= SEQUENCE {

   issuer     Name,
   subject    Name
   }

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

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

GetCert and GetCRL

The messageData for these types consist of an IssuerAndSerialNumber, as defined in 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, the message must contain the authenticatedAttributes specified in Section 3.2.1.

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 Section 7.8). Implementations SHOULD prefer HTTP certificate-store access RFC4387 or LDAP over the use of these messages.

Degenerate certificates-only CMS SignedData

CMS includes a degenerate case of the SignedData content type in which there are no signers. The use of such a degenerate case is to disseminate certificates and CRLs. For SCEP, the content field of the ContentInfo value of a degenerate certificates-only SignedData MUST be omitted. When carrying certificates, the certificates are included in the certificates field of the SignedData. When carrying a CRL, the CRL is included in the crls field of the SignedData.

CA Capabilities

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

GetCACaps HTTP Message Format

This message requests capabilities from a CA, with the format as described in Section 4.1:

"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF

CA Capabilities Response Format

The response for a GetCACaps message is a list of CA capabilities, in plain text and in any order, separated by <CR><LF> or <LF> characters. This specification defines the following keywords (quotation marks are not sent):

            Table 7: GetCACaps Response Keywords

Table 7 lists all of the keywords that are defined in this specification. A CA MAY provide additional keywords advertising further capabilities and functionality. A client MUST be able to accept and ignore any unknown keywords that might be sent by a CA.

The CA MUST use the text case specified here, but clients SHOULD ignore the text case when processing this message. Clients MUST accept the standard HTTP-style text delimited by <CR><LF> as well as the text delimited by <LF> specified in an earlier draft version of this specification.

The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES128-CBC in preference to triple DES-CBC if they are supported by the CA. Although the CMS format allows any form of AES and SHA-2 to be specified, in the interests of interoperability the de facto universal standards of AES128-CBC and SHA-256 SHOULD be used.

Announcing some of these capabilities individually is redundant, since they're required as mandatory-to-implement functionality (see Section 2.9) whose presence as a whole is signalled by the "SCEPStandard" 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.

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

Note that at least one widely deployed server implementation supports several of the above operations but doesn't support the GetCACaps message to indicate that it supports them, and 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, even if AES and/or SHA-2 are allegedly supported. In addition, the server will generate CA certificates that only have one, but not both, of the keyEncipherment and digitalSignature keyUsage flags set, requiring that the client ignore the keyUsage flags in order to use the certificates for SCEP.

The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore the Content-type, as older implementations of SCEP may send various Content-types.

Example:

GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1

might return:

AES GetNextCACert POSTPKIOperation SCEPStandard SHA-256

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

SCEP Transactions

This section describes the SCEP Transactions and their HTTP RFC7230 transport mechanism.

Note that SCEP doesn't follow best current practices on usage of HTTP. In particular, it recommends ignoring some media types and hard-codes specific URI paths. Guidance on the appropriate application of HTTP in these circumstances may be found in [HTTP].

HTTP POST and GET Message Formats

SCEP uses the HTTP POST and GET methods RFC7230 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:

POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION

             SP HTTP-version CRLF

GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION

            "&message=" MESSAGE SP HTTP-version CRLF

where:

SCEPPATH is the HTTP URL path for accessing the CA. Clients

  SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe"
  unless directed to do otherwise by the CA.

OPERATION depends on the SCEP transaction and is defined in the

  following sections.

HTTP-version is the HTTP version string, which is "HTTP/1.1" for

  RFC7230.

SP and CRLF are space and carriage return/linefeed, as defined in

  RFC5234.

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

Early SCEP drafts performed all communications via GET messages, including non-idempotent ones that should have been sent via POST messages; see [HTTP] 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 be sent via HTTP POST instead of HTTP GET. This applies to any SCEP message except GetCACert, GetNextCACert, and GetCACaps and avoids the need for base64 and URL encoding that's required for GET messaging. The client can verify that the CA supports SCEP messages via POST by looking for the "SCEPStandard" or "POSTPKIOperation" capability (see Section 3.5.2).

If a client or CA uses HTTP GET and encounters HTTP-related problems such as messages being truncated, seeing errors such as HTTP 414 ("Request-URI too long"), or simply having the message not sent/ received at all when standard requests to the server (for example, via a web browser) work, then this is a symptom of the problematic use of HTTP GET. The solution to this problem is to update the implementation to use HTTP POST instead. In addition, when using GET, it's recommended to test the implementation from as many different network locations as possible to determine whether the use of GET will cause problems with communications.

When using GET messages to communicate binary data, base64 encoding as specified in Section 4 of RFC4648 MUST be used. The base64-encoded data is distinct from "base64url" and may contain URI reserved characters; thus, it MUST be escaped as specified in RFC3986 in addition to being base64 encoded. Finally, the encoded data is inserted into the MESSAGE portion of the HTTP GET request.

Get CA Certificate

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

Get CA Certificate Response Message Format

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.

CA Certificate Response Message Format

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".

"Content-Type: application/x-x509-ca-cert"

CA Certificate Chain Response Message Format

If the CA has intermediate CA certificates, the response consists of a degenerate certificates-only CMS SignedData message (Section 3.4) containing the certificates, with the intermediate CA certificate(s) as the leaf certificate(s). The response will have a Content-Type of "application/x-x509-ca-ra-cert". Note that this designation is used for historical reasons due to its use in older versions of this specification -- no special meaning should be attached to the label.

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

Certificate Enrolment/Renewal

A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a certificate enrolment or renewal transaction. The OPERATION MUST be set to "PKIOperation". Note that when used with HTTP POST, the only OPERATION possible is "PKIOperation", so many CAs don't check this value or even notice its absence. When implemented using HTTP POST, the message is sent with a Content-Type of "application/x-pki- message" and might look as follows:

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

When implemented using HTTP GET, this might look as follows:

GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \

Certificate Enrolment/Renewal Response Message

If the request is granted, a CertRep SUCCESS message (Section 3.3.2.1) is returned. If the request is rejected, a CertRep FAILURE message (Section 3.3.2.2) is returned. If the CA is configured to manually authenticate the client, a CertRep PENDING message (Section 3.3.2.3) MAY be returned. The CA MAY return a PENDING for other reasons.

The response will have a Content-Type of "application/x-pki-message".

"Content-Type: application/x-pki-message"

Poll for Client Initial Certificate

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

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

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

Polling Response Message Format

The response messages for CertPoll are the same as in Section 4.3.1.

Certificate Access

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

This transaction consists of one GetCert (Section 3.3.4) message sent to the CA by a client and one CertRep (Section 3.3.2) message sent back from the CA. The OPERATION MUST be set to "PKIOperation".

Certificate Access Response Message Format

In this case, the CertRep from the CA is same as in Section 4.3.1, except that the CA will either grant the request (SUCCESS) or reject it (FAILURE).

CRL Access

Clients can request a CRL from the SCEP CA, as described in Section 2.7. The OPERATION MUST be set to "PKIOperation".

CRL Access Response Message Format

The CRL is sent back to the client in a CertRep (Section 3.3.2) message. The information portion of this message is a degenerate certificates-only SignedData (Section 3.4) that contains only the most recent CRL in the crls field of the SignedData.

Get Next Certificate Authority Certificate

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

Get Next CA Response Message Format

The response consists of a SignedData CMS message, signed by the current CA signing key. Clients MUST 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".

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

The content of the SignedData message is a degenerate certificates- only SignedData message (Section 3.4) containing the new CA certificate(s) to be used when the current CA certificate expires.

SCEP Transaction Examples

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

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

Successful Transactions

PKCSReq (1) ----------> CA issues certificate

                       <---------- CertRep (1) SUCCESS

Client installs certificate

     Figure 7: Successful Enrolment Case: Automatic Processing

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

Figure 8: Successful Enrolment Case: Manual Authentication Required

GetNextCACert ---------->

                     <---------- New CA certificate

PKCSReq* ----------> CA issues certificate with

                                 new key
                     <---------- CertRep SUCCESS

Client stores certificate for installation when existing certificate expires.

               Figure 9: CA Certificate Rollover Case

Enveloped for the new CA certificate. The CA will use the envelope

to determine which key to use to issue the client certificate.

Transactions with Errors

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

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

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

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

Resync Case 1: Client resyncs via new PKCSReq (recommended):

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...

                      Figure 10: Resync Case 1

Resync Case 2: Client resyncs via resumed CertPoll after a network outage (not recommended; use PKCSReq to resync):

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

                      Figure 11: Resync Case 2

Resync Case 3: Special-case variation of Case 2 where the CertRep SUCCESS rather than the CertRep PENDING is lost (recommended):

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
                                 Distinguished Name (DN).
                     <---------- CertRep (7) FAILURE
                                 Admin revokes certificate

PKCSReq (8) ----------> CA issues new certificate

                     <---------- CertRep (8) SUCCESS

Client installs certificate

                      Figure 12: Resync Case 3

Resync Case 4: Special-case variation of Case 1 where the CertRep SUCCESS rather than the CertRep PENDING is lost (not recommended; use PKCSReq to resync):

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

                      Figure 13: Resync Case 4

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

IANA Considerations

An object identifier for an arc to assign SCEP Attribute Identifiers has been assigned in the "SMI Security for PKIX" registry (1.3.6.1.5.5.7). This object identifer, Simple Certificate Enrollment Protocol Attributes, is denoted as id-scep:

id-scep OBJECT IDENTIFIER ::= { id-pkix 24 }

IANA created the "SMI Security for SCEP Attribute Identifiers" registry (1.3.6.1.5.5.7.24) with the following entries with references to this document:

id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }

Entries in the registry are assigned according to the "Specification Required" policy defined in RFC8126.

Section 3.2.1.2 describes an "SCEP Message Type" registry, and Section 3.5 describes an "SCEP CA Capabilities" registry; these registries are maintained by IANA and define a number of such code- point identifiers. Entries in the registry are assigned according to the "Specification Required" policy defined in RFC8126.

The "SCEP Message Types" registry has "Value", "Name", "Description", and "Reference" columns. The "Value" entry is a small positive integer; value "0" is reserved.

The "SCEP CA Capabilities" registry has "Keyword", "Description", and "Reference" columns. Although implementations SHOULD use the "SCEP CA Capabilities" registry, SCEP is often employed in situations where this isn't possible. In this case, private-use CA capabilities may be specified using a unique prefix such as an organisation identifier or domain name under the control of the entity that defines the capability. For example, the prefix would be "Example.com-", and the complete capability would be "Example.com-CapabilityName".

IANA has registered four media types as defined in this document:

application/x-x509-ca-cert

application/x-x509-ca-ra-cert

application/x-x509-next-ca-cert

application/x-pki-message

Note that these are grandfathered media types registered as per Appendix A of RFC6838. Templates for registrations are specified below.

Registration of the application/x-x509-ca-cert Media Type

Type name: application

Subtype name: x-x509-ca-cert

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations: This media type contains a certificate; see

  the Security Considerations section of RFC5280.  There is no
  executable content.

Interoperability considerations: This is a grandfathered

  registration of an alias to application/pkix-cert (basically a
  single DER-encoded Certification Authority certificate), which is
  only used in SCEP.

Published specification: RFC 8894

Applications that use this media type: SCEP uses this media type

  when returning a CA certificate.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type:  N/A

  Magic number(s):  none

  File extension(s):  N/A

  Macintosh file type code(s):  N/A

Person and email address to contact for further information: See the

  Authors' Addresses section of RFC 8894.

Intended usage: LIMITED USE

Restrictions on usage: SCEP protocol

Author: See the Authors' Addresses section of RFC 8894

Change controller: IETF

Provisional registration? No

Registration of the application/x-x509-ca-ra-cert Media Type

Type name: application

Subtype name: x-x509-ca-ra-cert

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations: This media type consists of a degenerate

  certificates-only CMS SignedData message (Section 3.4) containing
  the certificates, with the intermediate CA certificate(s) as the
  leaf certificate(s).  There is no executable content.

Interoperability considerations: This is a grandfathered

  registration that is only used in SCEP.

Published specification: RFC 8894

Applications that use this media type: SCEP uses this media type

  when returning CA Certificate Chain Response.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type:  N/A

  Magic number(s):  none

  File extension(s):  N/A

  Macintosh file type code(s):  N/A

Person and email address to contact for further information: See the

  Authors' Addresses section of RFC 8894.

Intended usage: LIMITED USE

Restrictions on usage: SCEP protocol

Author: See the Authors' Addresses section of RFC 8894.

Change controller: IETF

Provisional registration? no

Registration of the application/x-x509-next-ca-cert Media Type

Type name: application

Subtype name: x-x509-next-ca-cert

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations: This media type consists of a SignedData

  CMS message, signed by the current CA signing key.  There is no
  executable content.

Interoperability considerations: This is a grandfathered

  registration that is only used in SCEP.

Published specification: RFC 8894

Applications that use this media type: SCEP uses this media type

  when returning a Get Next CA response.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type:  N/A

  Magic number(s):  none

  File extension(s):  N/A

  Macintosh file type code(s):  N/A

Person and email address to contact for further information: See the

  Authors' Addresses section of RFC 8894.

Intended usage: LIMITED USE

Restrictions on usage: SCEP protocol

Author: See the Authors' Addresses section of RFC 8894.

Change controller: IETF

Provisional registration? no

Registration of the application/x-pki-message Media Type

Type name: application

Subtype name: x-pki-message

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations: This media type consists of a degenerate

  certificates-only CMS SignedData message.  There is no executable
  content.

Interoperability considerations: This is a grandfathered

  registration that is only used in SCEP.

Published specification: RFC 8894

Applications that use this media type: SCEP uses this media type

  when returning a Certificate Enrolment/Renewal Response.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type:  N/A

  Magic number(s):  none

  File extension(s):  N/A

  Macintosh file type code(s):  N/A

Person and email address to contact for further information: See the

  Authors' Addresses section of RFC 8894.

Intended usage: LIMITED USE

Restrictions on usage: SCEP protocol

Author: See the Authors' Addresses section of RFC 8894.

Change controller: IETF

Provisional registration? no

Security Considerations

The security goal of SCEP is that no adversary can subvert the public key/identity binding from that intended. An adversary is any entity other than the client and the CA participating in the protocol.

This goal is met through the use of CMS and PKCS #10 encryption and digital signatures using authenticated public keys. The CA's public key is authenticated via out-of-band means such as the checking of the CA fingerprint, and the SCEP client's public key is authenticated through manual or preshared secret authentication.

General Security

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.

Use of the CA Private Key

A CA private key is generally meant for, and usually flagged as, being usable for certificate (and CRL) signing exclusively rather than data signing or encryption. The SCEP protocol, however, uses the CA private key to both sign and optionally encrypt CMS transport messages. This is generally considered undesirable, as it widens the possibility of an implementation weakness and provides an additional location where the private key must be used (and hence is slightly more vulnerable to exposure) and where a side-channel attack might be applied.

ChallengePassword Shared Secret Value

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, 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.

The challengePassword, despite its name, shouldn't be a

  conventional password but a high-entropy shared-secret
  authentication string.  Using the base64 encoding of a keying
  value generated or exchanged as part of standard device
  authentication protocols like the Extensible Authentication
  Protocol (EAP) or DNP3 Secure Authentication (DNP3-SA) makes for a
  good challengePassword.  The use of high-entropy shared secrets is
  particularly important when the PasswordRecipientInfo option is
  used to encrypt SCEP messages; see Section 3.1.

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,
  then the arrival of subsequent requests using the same
  challengePassword can then be used to indicate a security breach.

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 -- for example, by compromising the device
  that it's stored in.

The CA should take appropriate measures to protect the

  challengePassword.  Examples of possible measures include:
  physical security measures; storing it as a salted iterated hash
  or equivalent memory-hard function; storing it as a keyed MAC
  value if it's not being used for encryption; and storing it in
  encrypted form if it is being used for encryption.

Lack of Certificate Issue Confirmation

SCEP provides no confirmation that the issued certificate was successfully received and processed by the client. This means that if the CertRep message is lost or can't be processed by the client, then the CA will consider the certificate successfully issued while the client won't. If this situation is of concern, then the correct issuance of the certificate will need to be verified by out-of-band means, for example, through the client sending a message signed by the newly issued certificate to the CA. This also provides the proof of possession that's not present in the case of a renewal operation; see Section 7.6.

GetCACaps Issues

The GetCACaps response is not authenticated by the CA. This allows an attacker to perform downgrade attacks on the cryptographic capabilities of the client/CA exchange. In particular, if the server were to support MD5 and single DES, then an in-path attacker could trivially roll back the encryption to use these insecure algorithms. By taking advantage of the presence of large amounts of static known plaintext in the SCEP messages, as of 2017, a DES rainbow table attack can recover most encryption keys in under a minute, and MD5 chosen-prefix collisions can be calculated for a few tens of cents of computing time using tools like HashClash. It is for this reason that this specification makes single DES and MD5 a MUST NOT 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.

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 trade-off between compatibility with old servers and security against active attacks.

Lack of PoP in Renewal Requests

Renewal operations (but not standard certificate-issue operations) are processed via a previously issued certificate and its associated private key, not the key in the PKCS #10 request. This means that a client no longer demonstrates proof of possession (PoP) of the private key corresponding to the public key in the PKCS #10 request. It is therefore possible for a client to 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 S/MIME ESS RFC2634.

Avoiding these types of attacks requires situation-specific measures. For example, CMS/SMIME implementations may use the ESSCertID attribute from S/MIME ESS RFC2634 or its successor, S/MIME ESSv2 RFC5035, to unambiguously identify the signing certificate. 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.

Traffic Monitoring

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) 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, then RFC7258 should be consulted for guidance.

Unnecessary Cryptography

Some of the SCEP exchanges use unnecessary signing and encryption operations. In particular, the GetCert and GetCRL exchanges are encrypted and signed in both directions. The information requested is public, and thus encrypting the requests is of questionable value. In addition, CRLs and certificates sent in responses are already signed by the CA and can be verified by the recipient without requiring additional signing and encryption. More lightweight means of retrieving certificates and CRLs such as HTTP certificate-store access RFC4387 and LDAP are recommended for this reason.

Use of SHA-1

The majority of the large 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, 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.

The second reason is that the signature over the message -- in other words, the SHA-1 hash that isn't protected by encryption -- doesn't serve any critical cryptographic purpose: The PKCS #10 data itself is authenticated through its 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.

The third reason is that SCEP uses the same key for encryption and signing, so that even if an attacker were able to capture an outgoing renewal request that didn't include a shared secret (in other 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 Section 7.8 points out that SCEP uses unnecessary cryptography in places, the additional level of security provided by the extra crypto makes it immune to any issues with SHA-1.

This doesn't mean that SCEP implementations should continue to use SHA-1 in perpetuity, merely that there's no need for a panicked switch to SHA-2.

7.10. Use of HTTP

SCEP is an encrypted, authenticated certificate enrollment protocol that uses HTTP as a simple transport mechanism. Since SCEP messages are already cryptographically secured, it does not require transport layer security. Where HTTPS is elected, a performance hit may result from the TLS overhead, operational problems may result due to the more complex configuration, and potential security vulnerability may result due to the addition of an entire TLS protocol stack alongside the basic SCEP protocol.

In particular, experience has shown that the issue of configuring certificates, CAs, and trust for both TLS and SCEP often leads to interoperability problems because different certificates and trust models are used in each. Use of HTTPS to authenticate the server does not enable omission of the ChallengePassword or similar authenticator in the SCEP message on the assumption that using HTTPS instead of HTTP will somehow make this insecure usage secure again. HTTPS is not soy sauce for security and is unnecessary for SCEP, which uses cryptographically secured messages and does not require transport layer security.

References

Normative References

[AES] Technology, U. N. I. O. S. A., "The Advanced Encryption

          Standard (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197,
          November 2001, <https://doi.org/10.6028/NIST.FIPS.197>.

RFC2119 Bradner, S., "Key words for use in RFCs to Indicate

          Requirement Levels", BCP 14, RFC 2119,
          DOI 10.17487/RFC2119, March 1997,
          <https://www.rfc-editor.org/info/rfc2119>.

RFC2985 Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object

          Classes and Attribute Types Version 2.0", RFC 2985,
          DOI 10.17487/RFC2985, November 2000,
          <https://www.rfc-editor.org/info/rfc2985>.

RFC2986 Nystrom, M. and B. Kaliski, "PKCS #10: Certification

          Request Syntax Specification Version 1.7", RFC 2986,
          DOI 10.17487/RFC2986, November 2000,
          <https://www.rfc-editor.org/info/rfc2986>.

RFC3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

          Resource Identifier (URI): Generic Syntax", STD 66,
          RFC 3986, DOI 10.17487/RFC3986, January 2005,
          <https://www.rfc-editor.org/info/rfc3986>.

RFC4648 Josefsson, S., "The Base16, Base32, and Base64 Data

          Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
          <https://www.rfc-editor.org/info/rfc4648>.

RFC5234 Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax

          Specifications: ABNF", STD 68, RFC 5234,
          DOI 10.17487/RFC5234, January 2008,
          <https://www.rfc-editor.org/info/rfc5234>.

RFC5280 Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,

          Housley, R., and W. Polk, "Internet X.509 Public Key
          Infrastructure Certificate and Certificate Revocation List
          (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
          <https://www.rfc-editor.org/info/rfc5280>.

RFC5652 Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,

          RFC 5652, DOI 10.17487/RFC5652, September 2009,
          <https://www.rfc-editor.org/info/rfc5652>.

RFC6838 Freed, N., Klensin, J., and T. Hansen, "Media Type

          Specifications and Registration Procedures", BCP 13,
          RFC 6838, DOI 10.17487/RFC6838, January 2013,
          <https://www.rfc-editor.org/info/rfc6838>.

RFC7230 Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer

          Protocol (HTTP/1.1): Message Syntax and Routing",
          RFC 7230, DOI 10.17487/RFC7230, June 2014,
          <https://www.rfc-editor.org/info/rfc7230>.

RFC7258 Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an

          Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
          2014, <https://www.rfc-editor.org/info/rfc7258>.

RFC8126 Cotton, M., Leiba, B., and T. Narten, "Guidelines for

          Writing an IANA Considerations Section in RFCs", BCP 26,
          RFC 8126, DOI 10.17487/RFC8126, June 2017,
          <https://www.rfc-editor.org/info/rfc8126>.

RFC8174 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

          2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
          May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[SHA2] Technology, U. N. I. O. S. A., "Secure Hash Standard

          (SHS)", FIPS 180-3, October 2008.

Informative References

[HTTP] Nottingham, M., "Building Protocols with HTTP", Work in

          Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09,
          November 1, 2019, <https://tools.ietf.org/html/draft-ietf-
          httpbis-bcp56bis-09>.

[JSCEP] "A Java implementation of the Simple Certificate Enrolment

          Protocol", commit 7410332, January 2020,
          <https://github.com/jscep/jscep>.

RFC2634 Hoffman, P., Ed., "Enhanced Security Services for S/MIME",

          RFC 2634, DOI 10.17487/RFC2634, June 1999,
          <https://www.rfc-editor.org/info/rfc2634>.

RFC4387 Gutmann, P., Ed., "Internet X.509 Public Key

          Infrastructure Operational Protocols: Certificate Store
          Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February
          2006, <https://www.rfc-editor.org/info/rfc4387>.

RFC5035 Schaad, J., "Enhanced Security Services (ESS) Update:

          Adding CertID Algorithm Agility", RFC 5035,
          DOI 10.17487/RFC5035, August 2007,
          <https://www.rfc-editor.org/info/rfc5035>.

RFC7296 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.

          Kivinen, "Internet Key Exchange Protocol Version 2
          (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
          2014, <https://www.rfc-editor.org/info/rfc7296>.

RFC8446 Rescorla, E., "The Transport Layer Security (TLS) Protocol

          Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
          <https://www.rfc-editor.org/info/rfc8446>.

RFC8551 Schaad, J., Ramsdell, B., and S. Turner, "Secure/

          Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
          Message Specification", RFC 8551, DOI 10.17487/RFC8551,
          April 2019, <https://www.rfc-editor.org/info/rfc8551>.

Appendix A. Background Notes

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", then the SCEP document was its graveyard.

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

Note that although the text of the current specification has changed significantly due to the consolidation of features and appendices into the main document, the protocol 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.

Other changes include:

Resolved contradictions in the text -- for example, a requirement

  given as a MUST in one paragraph and a SHOULD in the next, a MUST
  NOT in one paragraph and a MAY a few paragraphs later, a SHOULD
  NOT contradicted later by a MAY, and so on.

Merged several later fragmentary addenda placed in appendices (for

  example, the handling of certificate renewal) with the body of the
  text.

Merged the "SCEP Transactions" and "SCEP Transport" sections,

  since the latter mostly duplicated (with occasional
  inconsistencies) the former.

Updated the algorithms to ones dating from at least this century.

Did the same for normative references to other standards.

Updated the text to use consistent terminology for the client and

  CA rather than a mixture of client, requester, requesting system,
  end entity, server, certificate authority, certification
  authority, and CA.

Corrected incorrect references to other standards, e.g.,

  IssuerAndSerial -> IssuerAndSerialNumber.

Corrected errors such as a statement that when both signature and

  encryption certificates existed, the signature certificate was
  used for encryption.

Condensed redundant discussions of the same topic spread across

  multiple sections into a single location.  For example, the
  description of intermediate CA handling previously existed in
  three different locations, with slightly different requirements in
  each one.

Added a description of how pkiMessages were processed, which was

  never made explicit in the original specification.  This led to
  creative interpretations that had security problems but were
  employed anyway due to the lack of specific guidance on what to
  do.

Relaxed some requirements that didn't serve any obvious purpose

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

Removed discussion of the transactionID from the security

  considerations, since the instructions there were directly
  contradicted by the discussion of the use of the transactionID in
  Section 5.

Added a requirement that the signed message include the signing

  certificate(s) in the signedData certificates field.  This was
  implicit in the original specification (without it, the message
  couldn't be verified by the CA) and was handled by the fact that
  most PKCS #7/CMS libraries do this by default, but was never
  explicitly mentioned.

Clarified sections that were unclear or even made no sense -- for

  example, the requirement for a "hash on the public key" [sic]
  encoded as a PrintableString.

Renamed "RA certificates" to "intermediate CA certificates". The

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

Redid the PKIMessage diagram to match what was specified in CMS;

  the original diagram omitted a number of fields and nested data
  structures, which meant that the diagram didn't match either the
  text or the CMS specification.

Removed the requirement for a CertPoll to contain a

  recipientNonce, since CertPoll is a client message and will never
  be sent in response to a message containing a senderNonce.  See
  also the note in Section 3.3.2.

Clarified certificate renewal. This represents a capability that

  was bolted onto the original protocol with (at best) vaguely
  defined semantics, including a requirement by the CA to guess
  whether a particular request was a renewal or not.  In response to
  developer feedback that they either avoided renewal entirely
  because of this uncertainty or hard-coded in particular behaviour
  on a per-CA basis, this specification explicitly identifies
  renewal requests as such and provides proper semantics for them.

Corrected the requirement that "undefined message types are

  treated as an error", since this negates the effect of GetCACaps,
  which is used to define new message types.  In 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.

In line with the above, added IANA registries for several entries

  that had previously been defined in an ad hoc manner in different
  locations in the text.

Added the "SCEPStandard" keyword to GetCACaps to indicate that the

  CA complies with the final version of the SCEP standard, since the
  definition of what constitutes SCEP standards compliance has
  changed significantly over the years.

Added the optional failInfoText attribute to deal with the fact

  that failInfo was incapable of adequately communicating to clients
  why a certificate request operation had been rejected.

Removed the discussion in the security considerations of

  revocation issues, since SCEP doesn't support revocation as part
  of the protocol.

Clarified the use of nonces, which if applied as originally

  specified would have made the use of polling in the presence of a
  lost message impossible.

Removed the discussion of generating a given transactionID by

  hashing the public key, since this implied that there was some
  special significance in the value generated this way.  Since it
  was neither a MUST nor a MAY, it was unsound to imply that servers
  could rely on the value being generated a certain way.  In
  addition, it wouldn't work if multiple transactions as discussed
  in Section 4.4 were initiated, since the deterministic generation
  via hashing would lead to duplicate transactionIDs.

Added examples of SCEP messages to give implementers something to

  aim for.

Acknowledgements

The editor would like to thank all of the previous editors, authors, and contributors for their work maintaining the document over the years: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy Nourse, Max Pritikin, 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.

The authors of earlier draft versions of this document would like to thank Peter William of ValiCert, Inc. (formerly of VeriSign, Inc.), Alex Deacon of VeriSign, Inc., and Christopher Welles of IRE, Inc. for their contributions to early versions of this protocol and this document.

Author's Address

Peter Gutmann University of Auckland Department of Computer Science Auckland New Zealand

Email: [email protected]

@@ Line 1: / Line 1: @@
 Internet Engineering Task Force (IETF)                        P. Gutmann
@@ Line 8: / Line 6: @@
 ISSN: 2070-1721
+              Simple Certificate Enrolment Protocol
-                Simple Certificate Enrolment Protocol
+'''Abstract'''
-Abstract
-  This document specifies the Simple Certificate Enrolment Protocol
+This document specifies the Simple Certificate Enrolment Protocol
-  (SCEP), a PKI protocol that leverages existing technology by using
+(SCEP), a PKI protocol that leverages existing technology by using
-  Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and
+Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and
-  PKCS #10 over HTTP.  SCEP is the evolution of the enrolment protocol
+PKCS #10 over HTTP.  SCEP is the evolution of the enrolment protocol
-  sponsored by Cisco Systems, which enjoys wide support in both client
+sponsored by Cisco Systems, which enjoys wide support in both client
-  and server implementations, as well as being relied upon by numerous
+and server implementations, as well as being relied upon by numerous
-  other industry standards that work with certificates.
+other industry standards that work with certificates.
-Status of This Memo
+'''Status of This Memo'''
-  This document is not an Internet Standards Track specification; it is
+This document is not an Internet Standards Track specification; it is
-  published for informational purposes.
+published for informational purposes.
-  This document is a product of the Internet Engineering Task Force
+This document is a product of the Internet Engineering Task Force
-  (IETF).  It represents the consensus of the IETF community.  It has
+(IETF).  It represents the consensus of the IETF community.  It has
-  received public review and has been approved for publication by the
+received public review and has been approved for publication by the
-  Internet Engineering Steering Group (IESG).  Not all documents
+Internet Engineering Steering Group (IESG).  Not all documents
-  approved by the IESG are candidates for any level of Internet
+approved by the IESG are candidates for any level of Internet
-  Standard; see Section 2 of RFC 7841.
+Standard; see Section 2 of [[RFC7841|RFC 7841]].
-  Information about the current status of this document, any errata,
+Information about the current status of this document, any errata,
-  and how to provide feedback on it may be obtained at
+and how to provide feedback on it may be obtained at
-  https://www.rfc-editor.org/info/rfc8894.
+https://www.rfc-editor.org/info/rfc8894.
-Copyright Notice
+'''Copyright Notice'''
-  Copyright (c) 2020 IETF Trust and the persons identified as the
+Copyright (c) 2020 IETF Trust and the persons identified as the
-  document authors.  All rights reserved.
+document authors.  All rights reserved.
-  This document is subject to BCP 78 and the IETF Trust's Legal
+This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal
-  Provisions Relating to IETF Documents
+Provisions Relating to IETF Documents
-  (https://trustee.ietf.org/license-info) in effect on the date of
+(https://trustee.ietf.org/license-info) in effect on the date of
-  publication of this document.  Please review these documents
+publication of this document.  Please review these documents
-  carefully, as they describe your rights and restrictions with respect
+carefully, as they describe your rights and restrictions with respect
-  to this document.  Code Components extracted from this document must
+to this document.  Code Components extracted from this document must
-  include Simplified BSD License text as described in Section 4.e of
+include Simplified BSD License text as described in Section 4.e of
-  the Trust Legal Provisions and are provided without warranty as
+the Trust Legal Provisions and are provided without warranty as
-  described in the Simplified BSD License.
+described in the Simplified BSD License.
-  This document may contain material from IETF Documents or IETF
+This document may contain material from IETF Documents or IETF
-  Contributions published or made publicly available before November
+Contributions published or made publicly available before November
 , 2008.  The person(s) controlling the copyright in some of this
-  material may not have granted the IETF Trust the right to allow
+material may not have granted the IETF Trust the right to allow
-  modifications of such material outside the IETF Standards Process.
+modifications of such material outside the IETF Standards Process.
-  Without obtaining an adequate license from the person(s) controlling
+Without obtaining an adequate license from the person(s) controlling
-  the copyright in such materials, this document may not be modified
+the copyright in such materials, this document may not be modified
-  outside the IETF Standards Process, and derivative works of it may
+outside the IETF Standards Process, and derivative works of it may
-  not be created outside the IETF Standards Process, except to format
+not be created outside the IETF Standards Process, except to format
-  it for publication as an RFC or to translate it into languages other
+it for publication as an RFC or to translate it into languages other
-  than English.
+than English.
-Table of Contents
-.  Introduction
-.1.  Conventions Used in This Document
-.  SCEP Overview
-.1.  SCEP Entities
-.1.1.  Client
-.1.2.  Certificate Authority
-.2.  CA Certificate Distribution
-.3.  Client Authentication
-.4.  Enrolment Authorisation
-.5.  Certificate Enrolment/Renewal
-.5.1.  Client State Transitions
-.6.  Certificate Access
-.7.  CRL Access
-.8.  Certificate Revocation
-.9.  Mandatory-to-Implement Functionality
-.  SCEP Secure Message Objects
-.1.  SCEP Message Object Processing
-.2.  SCEP pkiMessage
-.2.1.  Signed Transaction Attributes
-.2.1.1.  transactionID
-.2.1.2.  messageType
-.2.1.3.  pkiStatus
-.2.1.4.  failInfo and failInfoText
-.2.1.5.  senderNonce and recipientNonce
-.2.2.  SCEP pkcsPKIEnvelope
-.3.  SCEP pkiMessage types
-.3.1.  PKCSReq/RenewalReq
-.3.2.  CertRep
-.3.2.1.  CertRep SUCCESS
-.3.2.2.  CertRep FAILURE
-.3.2.3.  CertRep PENDING
-.3.3.  CertPoll (GetCertInitial)
-.3.4.  GetCert and GetCRL
-.4.  Degenerate certificates-only CMS SignedData
-.5.  CA Capabilities
-.5.1.  GetCACaps HTTP Message Format
-.5.2.  CA Capabilities Response Format
-.  SCEP Transactions
-.1.  HTTP POST and GET Message Formats
-.2.  Get CA Certificate
-.2.1.  Get CA Certificate Response Message Format
-.2.1.1.  CA Certificate Response Message Format
-.2.1.2.  CA Certificate Chain Response Message Format
-.3.  Certificate Enrolment/Renewal
-.3.1.  Certificate Enrolment/Renewal Response Message
-.4.  Poll for Client Initial Certificate
-.4.1.  Polling Response Message Format
-.5.  Certificate Access
-.5.1.  Certificate Access Response Message Format
-.6.  CRL Access
-.6.1.  CRL Access Response Message Format
-.7.  Get Next Certificate Authority Certificate
-.7.1.  Get Next CA Response Message Format
-.  SCEP Transaction Examples
-.1.  Successful Transactions
-.2.  Transactions with Errors
-.  IANA Considerations
-.1.  Registration of the application/x-x509-ca-cert Media Type
-.2.  Registration of the application/x-x509-ca-ra-cert Media
-          Type
-.3.  Registration of the application/x-x509-next-ca-cert Media
-          Type
-.4.  Registration of the application/x-pki-message Media Type
-.  Security Considerations
-.1.  General Security
-.2.  Use of the CA Private Key
-.3.  ChallengePassword Shared Secret Value
-.4.  Lack of Certificate Issue Confirmation
-.5.  GetCACaps Issues
-.6.  Lack of PoP in Renewal Requests
-.7.  Traffic Monitoring
-.8.  Unnecessary Cryptography
-.9.  Use of SHA-1
-.10. Use of HTTP
-.  References
-.1.  Normative References
-.2.  Informative References
-  Appendix A.  Background Notes
-  Acknowledgements
-  Author's Address
 .  Introduction
+.1.  Conventions Used in This Document
+.  SCEP Overview
+.1.  SCEP Entities
+.1.1.  Client
+.1.2.  Certificate Authority
+.2.  CA Certificate Distribution
+.3.  Client Authentication
+.4.  Enrolment Authorisation
+.5.  Certificate Enrolment/Renewal
+.5.1.  Client State Transitions
+.6.  Certificate Access
+.7.  CRL Access
+.8.  Certificate Revocation
+.9.  Mandatory-to-Implement Functionality
+.  SCEP Secure Message Objects
+.1.  SCEP Message Object Processing
+.2.  SCEP pkiMessage
+.2.1.  Signed Transaction Attributes
+.2.1.1.  transactionID
+.2.1.2.  messageType
+.2.1.3.  pkiStatus
+.2.1.4.  failInfo and failInfoText
+.2.1.5.  senderNonce and recipientNonce
+.2.2.  SCEP pkcsPKIEnvelope
+.3.  SCEP pkiMessage types
+.3.1.  PKCSReq/RenewalReq
+.3.2.  CertRep
+.3.2.1.  CertRep SUCCESS
+.3.2.2.  CertRep FAILURE
+.3.2.3.  CertRep PENDING
+.3.3.  CertPoll (GetCertInitial)
+.3.4.  GetCert and GetCRL
+.4.  Degenerate certificates-only CMS SignedData
+.5.  CA Capabilities
+.5.1.  GetCACaps HTTP Message Format
+.5.2.  CA Capabilities Response Format
+.  SCEP Transactions
+.1.  HTTP POST and GET Message Formats
+.2.  Get CA Certificate
+.2.1.  Get CA Certificate Response Message Format
+.2.1.1.  CA Certificate Response Message Format
+.2.1.2.  CA Certificate Chain Response Message Format
+.3.  Certificate Enrolment/Renewal
+.3.1.  Certificate Enrolment/Renewal Response Message
+.4.  Poll for Client Initial Certificate
+.4.1.  Polling Response Message Format
+.5.  Certificate Access
+.5.1.  Certificate Access Response Message Format
+.6.  CRL Access
+.6.1.  CRL Access Response Message Format
+.7.  Get Next Certificate Authority Certificate
+.7.1.  Get Next CA Response Message Format
+.  SCEP Transaction Examples
+.1.  Successful Transactions
+.2.  Transactions with Errors
+.  IANA Considerations
+.1.  Registration of the application/x-x509-ca-cert Media Type
+.2.  Registration of the application/x-x509-ca-ra-cert Media
+        Type
+.3.  Registration of the application/x-x509-next-ca-cert Media
+        Type
+.4.  Registration of the application/x-pki-message Media Type
+.  Security Considerations
+.1.  General Security
+.2.  Use of the CA Private Key
+.3.  ChallengePassword Shared Secret Value
+.4.  Lack of Certificate Issue Confirmation
+.5.  GetCACaps Issues
+.6.  Lack of PoP in Renewal Requests
+.7.  Traffic Monitoring
+.8.  Unnecessary Cryptography
+.9.  Use of SHA-1
+.10. Use of HTTP
+.  References
+.1.  Normative References
+.2.  Informative References
+Appendix A.  Background Notes
+Acknowledgements
+Author's Address
-  X.509 certificates serve as the basis for several standardised
+== Introduction ==
-  security protocols such as TLS [RFC8446], S/MIME [RFC8551], and IKE/
-  IPsec [RFC7296].  When an X.509 certificate is issued, there
-  typically is a need for a certificate management protocol to enable a
-  PKI client to request or renew a certificate from a Certificate
-  Authority (CA).  This specification defines a protocol, the Simple
-  Certificate Enrolment Protocol (SCEP), for certificate management and
-  certificate and CRL queries.
-  The SCEP protocol supports the following general operations:
+X.509 certificates serve as the basis for several standardised
+security protocols such as TLS [[RFC8446]], S/MIME [[RFC8551]], and IKE/
+IPsec [[RFC7296]].  When an X.509 certificate is issued, there
+typically is a need for a certificate management protocol to enable a
+PKI client to request or renew a certificate from a Certificate
+Authority (CA).  This specification defines a protocol, the Simple
+Certificate Enrolment Protocol (SCEP), for certificate management and
+certificate and CRL queries.
-  *  CA public key distribution
+The SCEP protocol supports the following general operations:
-  *  Certificate enrolment and issue
-  *  Certificate renewal
-  *  Certificate query
-  *  CRL query
-  SCEP makes extensive use of CMS [RFC5652] and PKCS #10 [RFC2986].
+*  CA public key distribution
+*  Certificate enrolment and issue
+*  Certificate renewal
+*  Certificate query
+*  CRL query
-.1.  Conventions Used in This Document
+SCEP makes extensive use of CMS [[RFC5652]] and PKCS #10 [[RFC2986]].
-  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+=== Conventions Used in This Document ===
-  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-  "OPTIONAL" in this document are to be interpreted as described in
-  BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
-  capitals, as shown here.
-  This document uses the Augmented Backus-Naur Form (ABNF) notation as
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-  specified in [RFC5234] for defining formal syntax of commands.  Non-
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-  terminals not defined in [RFC5234] are defined in Section 4.1.
+"OPTIONAL" in this document are to be interpreted as described in
+[[BCP14|BCP 14]] [[RFC2119]] [[RFC8174]] when, and only when, they appear in all
+capitals, as shown here.
-.  SCEP Overview
+This document uses the Augmented Backus-Naur Form (ABNF) notation as
+specified in [[RFC5234]] for defining formal syntax of commands.  Non-
+terminals not defined in [[RFC5234]] are defined in Section 4.1.
-  This section provides an overview of the functionality of SCEP.
+== SCEP Overview ==
-.1.  SCEP Entities
+This section provides an overview of the functionality of SCEP.
-  The entity types defined in SCEP are a client requesting a
+=== SCEP Entities ===
-  certificate and a Certificate Authority (CA) that issues the
-  certificate.  These are described in the following sections.
-.1.1.  Client
+The entity types defined in SCEP are a client requesting a
+certificate and a Certificate Authority (CA) that issues the
+certificate.  These are described in the following sections.
-  A client MUST have the following information locally configured:
+==== Client ====
-.  The CA's fully qualified domain name or IP address.
+A client MUST have the following information locally configured:
-.  Any identification and/or authorisation information required by
+.  The CA's fully qualified domain name or IP address.
-      the CA before a certificate will be issued, as described in
-      Section 3.3.1.
-.  The identifying information that is used for authentication of
+.  Any identification and/or authorisation information required by
-      the CA in Section 4.2.1, typically a certificate fingerprint.
+    the CA before a certificate will be issued, as described in
+    Section 3.3.1.
-.1.2.  Certificate Authority
+.  The identifying information that is used for authentication of
+    the CA in Section 4.2.1, typically a certificate fingerprint.
-  A SCEP CA is the entity that signs client certificates.  A CA may
+==== Certificate Authority ====
-  enforce policies and apply them to certificate requests, and it may
-  reject a request for any reason.
-  Since the client is expected to perform signature verification and
+A SCEP CA is the entity that signs client certificates.  A CA may
-  optionally encryption using the CA certificate, the keyUsage
+enforce policies and apply them to certificate requests, and it may
-  extension in the CA certificate MUST indicate that it is valid for
+reject a request for any reason.
-  digitalSignature and keyEncipherment (if the key is to be used for
-  en/decryption) alongside the usual CA usages of keyCertSign and/or
-  cRLSign.
-.2.  CA Certificate Distribution
+Since the client is expected to perform signature verification and
+optionally encryption using the CA certificate, the keyUsage
+extension in the CA certificate MUST indicate that it is valid for
+digitalSignature and keyEncipherment (if the key is to be used for
+en/decryption) alongside the usual CA usages of keyCertSign and/or
+cRLSign.
-  If the CA certificate(s) have not previously been acquired by the
+=== CA Certificate Distribution ===
-  client through some other means, the client MUST retrieve them before
-  any PKI operation (Section 3) 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.
-  If an intermediate CA is in use, a certificates-only CMS SignedData
+If the CA certificate(s) have not previously been acquired by the
-  message with a certificate chain consisting of all CA certificates is
+client through some other means, the client MUST retrieve them before
-  returned.  Otherwise, the CA certificate itself is returned.
+any PKI operation (Section 3) 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.
-  The CA certificate MAY be provided out of band to the client.
+If an intermediate CA is in use, a certificates-only CMS SignedData
-  Alternatively, the CA certificate fingerprint MAY be used to
+message with a certificate chain consisting of all CA certificates is
-  authenticate a CA certificate distributed by the GetCACert response
+returned.  Otherwise, the CA certificate itself is returned.
-  (Section 4.2) or via HTTP certificate-store access [RFC4387].  The
-  fingerprint is created by calculating a SHA-256 hash over the whole
-  CA certificate.  (For legacy reasons, a SHA-1 hash may be used by
-  some implementations.)
-  After the client gets the CA certificate, it SHOULD authenticate it
+The CA certificate MAY be provided out of band to the client.
-  in some manner unless this is deemed unnecessary, for example,
+Alternatively, the CA certificate fingerprint MAY be used to
-  because the device is being provisioned inside a trusted environment.
+authenticate a CA certificate distributed by the GetCACert response
-  For example, the client could compare the certificate's fingerprint
+(Section 4.2) or via HTTP certificate-store access [[RFC4387]].  The
-  with locally configured, out-of-band distributed, identifying
+fingerprint is created by calculating a SHA-256 hash over the whole
-  information, or by some equivalent means such as a direct comparison
+CA certificate.  (For legacy reasons, a SHA-1 hash may be used by
-  with a locally stored copy of the certificate.
+some implementations.)
-  Intermediate CA certificates, if any, are signed by a higher-level
+After the client gets the CA certificate, it SHOULD authenticate it
-  CA, so there is no need to authenticate them against the out-of-band
+in some manner unless this is deemed unnecessary, for example,
-  data.  Since intermediate CA certificates are rolled over more
+because the device is being provisioned inside a trusted environment.
-  frequently than long-lived top-level CA certificates, clients MUST
+For example, the client could compare the certificate's fingerprint
-  verify intermediate-level CA certificates before use during protocol
+with locally configured, out-of-band distributed, identifying
-  exchanges in case the intermediate CA certificate has expired or
+information, or by some equivalent means such as a direct comparison
-  otherwise been invalidated.
+with a locally stored copy of the certificate.
-  When a CA certificate expires, certificates that have been signed by
+Intermediate CA certificates, if any, are signed by a higher-level
-  it may no longer be regarded as valid.  CA key rollover provides a
+CA, so there is no need to authenticate them against the out-of-band
-  mechanism by which the CA can distribute a new CA certificate that
+data.  Since intermediate CA certificates are rolled over more
-  will be valid in the future once the current certificate has expired.
+frequently than long-lived top-level CA certificates, clients MUST
-  This is done via the GetNextCACert message (Section 4.7).
+verify intermediate-level CA certificates before use during protocol
+exchanges in case the intermediate CA certificate has expired or
+otherwise been invalidated.
-.3.  Client Authentication
+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 that
+will be valid in the future once the current certificate has expired.
+This is done via the GetNextCACert message (Section 4.7).
-  As with every protocol that uses public-key cryptography, the
+=== Client Authentication ===
-  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 Section 3, which specifies how CMS is used to encrypt and sign the
-  data.  In order to perform the signing operation, the client uses an
-  appropriate local certificate:
-.  If the client does not have an appropriate existing certificate,
+As with every protocol that uses public-key cryptography, the
-      then a locally generated self-signed certificate MUST be used.
+association between the public keys used in the protocol and the
-      The keyUsage extension in the certificate MUST indicate that it
+identities with which they are associated must be authenticated in a
-      is valid for digitalSignature and keyEncipherment (if available).
+cryptographically secure manner.  Communications between the client
-      The self-signed certificate SHOULD use the same subject name and
+and the CA are secured using SCEP Secure Message Objects as explained
-      key as in the PKCS #10 request.  In this case, the messageType is
+in Section 3, which specifies how CMS is used to encrypt and sign the
-      PKCSReq (see Section 3.2.1.2).
+data.  In order to perform the signing operation, the client uses an
+appropriate local certificate:
-.  If the client already has a certificate issued by the SCEP CA,
+.  If the client does not have an appropriate existing certificate,
-      and the CA supports renewal (see Section 2.5), that certificate
+    then a locally generated self-signed certificate MUST be used.
-      SHOULD be used.  In this case, the messageType is RenewalReq (see
+    The keyUsage extension in the certificate MUST indicate that it
-      Section 3.2.1.2).
+    is valid for digitalSignature and keyEncipherment (if available).
+    The self-signed certificate SHOULD use the same subject name and
+    key as in the PKCS #10 request.  In this case, the messageType is
+    PKCSReq (see Section 3.2.1.2).
-.  Alternatively, if the client has no certificate issued by the
+.  If the client already has a certificate issued by the SCEP CA,
-      SCEP CA but has credentials from an alternate CA, then the
+    and the CA supports renewal (see Section 2.5), that certificate
-      certificate issued by the alternate CA MAY be used in a renewal
+    SHOULD be used.  In this case, the messageType is RenewalReq (see
-      request as described above.  The SCEP CA's policy will determine
+    Section 3.2.1.2).
-      whether the request can be accepted or not.
-  Note that although the above text describes several different types
+.  Alternatively, if the client has no certificate issued by the
-  of operations, for historical reasons, most implementations always
+    SCEP CA but has credentials from an alternate CA, then the
-  apply the first one, even if an existing certificate already exists.
+    certificate issued by the alternate CA MAY be used in a renewal
-  For this reason, support for the first case is mandatory while
+    request as described above.  The SCEP CA's policy will determine
-  support for the latter ones are optional (see Section 2.9).
+    whether the request can be accepted or not.
-  During the certificate-enrolment process, the client MUST use the
+Note that although the above text describes several different types
-  selected certificate's key when signing the CMS envelope (see
+of operations, for historical reasons, most implementations always
-  Section 3).  This certificate will be either the self-signed one
+apply the first one, even if an existing certificate already exists.
-  matching the PKCS #10 request or the CA-issued one used to authorise
+For this reason, support for the first case is mandatory while
-  a renewal, and it MUST be included in the signedData certificates
+support for the latter ones are optional (see Section 2.9).
-  field (possibly as part of a full certificate chain).  If the key
-  being certified allows encryption, then the CA's CertResp will use
-  the same certificate's public key when encrypting the response.
-  Note that, in the case of renewal operations, this means that the
+During the certificate-enrolment process, the client MUST use the
-  request will be signed and authenticated with the key in the
+selected certificate's key when signing the CMS envelope (see
-  previously issued certificate rather than the key in the PKCS #10
+Section 3).  This certificate will be either the self-signed one
-  request, and the response may similarly be returned encrypted with
+matching the PKCS #10 request or the CA-issued one used to authorise
-  the key in the previously issued certificate.  This has security
+a renewal, and it MUST be included in the signedData certificates
-  implications; see Section 7.6.
+field (possibly as part of a full certificate chain).  If the key
+being certified allows encryption, then the CA's CertResp will use
+the same certificate's public key when encrypting the response.
-.4.  Enrolment Authorisation
+Note that, in the case of renewal operations, this means that the
+request will be signed and authenticated with the key in the
+previously issued certificate rather than the key in the PKCS #10
+request, and the response may similarly be returned encrypted with
+the key in the previously issued certificate.  This has security
+implications; see Section 7.6.
-  PKCS #10 [RFC2986] specifies a PKCS #9 [RFC2985] challengePassword
+=== Enrolment Authorisation ===
-  attribute to be sent as part of the enrolment request.  When
-  utilising the challengePassword, the CA distributes a shared secret
-  to the client, which will be used to authenticate the request from
-  the client.  It is RECOMMENDED 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 and reuse it to
-  request further certificates.
-  Inclusion of the challengePassword by the SCEP client is RECOMMENDED;
+PKCS #10 [[RFC2986]] specifies a PKCS #9 [[RFC2985]] challengePassword
-  however, its omission allows for unauthenticated authorisation of
+attribute to be sent as part of the enrolment request.  When
-  enrolment requests (which may, however, require manual approval of
+utilising the challengePassword, the CA distributes a shared secret
-  each certificate issue if other security measures to control issue
+to the client, which will be used to authenticate the request from
-  aren't in place; see below).  Inclusion is OPTIONAL for renewal
+the client.  It is RECOMMENDED that the challengePassword be a one-
-  requests that are authenticated by being signed with an existing
+time authenticator value to limit the ability of an attacker who can
-  certificate.  The CMS envelope protects the privacy of the
+capture the authenticator from the client or CA and reuse it to
-  challengePassword.
+request further certificates.
-  A client that is performing certificate renewal as per Section 2.5
+Inclusion of the challengePassword by the SCEP client is RECOMMENDED;
-  SHOULD omit the challengePassword but MAY send the originally
+however, its omission allows for unauthenticated authorisation of
-  distributed shared secret in the challengePassword attribute.  The
+enrolment requests (which may, however, require manual approval of
-  SCEP CA MAY authenticate the request using the challengePassword in
+each certificate issue if other security measures to control issue
-  addition to the previously issued certificate that signs the request.
+aren't in place; see below).  Inclusion is OPTIONAL for renewal
-  The SCEP CA MUST NOT attempt to authenticate a client based on a
+requests that are authenticated by being signed with an existing
-  self-signed certificate unless it has been verified through out-of-
+certificate.  The CMS envelope protects the privacy of the
-  band means such as a certificate fingerprint.
+challengePassword.
-  To perform the authorisation in manual mode, the client's request is
+A client that is performing certificate renewal as per Section 2.5
-  placed in the PENDING state until the CA operator authorises or
+SHOULD omit the challengePassword but MAY send the originally
-  rejects it.  Manual authorisation is used when the client has only a
+distributed shared secret in the challengePassword attribute.  The
-  self-signed certificate that hasn't been previously authenticated by
+SCEP CA MAY authenticate the request using the challengePassword in
-  the CA and/or a challengePassword is not available.  The SCEP CA MAY
+addition to the previously issued certificate that signs the request.
-  either reject unauthorised requests or mark them for manual
+The SCEP CA MUST NOT attempt to authenticate a client based on a
-  authorisation according to CA policy.
+self-signed certificate unless it has been verified through out-of-
+band means such as a certificate fingerprint.
-.5.  Certificate Enrolment/Renewal
+To perform the authorisation in manual mode, the client's request is
+placed in the PENDING state until the CA operator authorises or
+rejects it.  Manual 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
+either reject unauthorised requests or mark them for manual
+authorisation according to CA policy.
-  A client starts an enrolment transaction (Section 3.3.1) by creating
+=== Certificate Enrolment/Renewal ===
-  a certificate request using PKCS #10 and sends the request to the CA
-  enveloped using CMS (Section 3).
-  If the CA supports certificate renewal and the CA policy permits,
+A client starts an enrolment transaction (Section 3.3.1) by creating
-  then a new certificate with new validity dates can be issued, even
+a certificate request using PKCS #10 and sends the request to the CA
-  though the old one is still valid.  To renew an existing certificate,
+enveloped using CMS (Section 3).
-  the client uses the RenewalReq message (see Section 3.3) and signs it
-  with the existing client certificate.  The client SHOULD use a new
-  keypair when requesting a new certificate but MAY request a new
-  certificate using the old keypair.
-  If the CA returns a CertRep message (Section 3.3.2) with status set
+If the CA supports certificate renewal and the CA policy permits,
-  to PENDING, the client enters into polling mode by periodically
+then a new certificate with new validity dates can be issued, even
-  sending a CertPoll message (Section 3.3.3) to the CA until the CA
+though the old one is still valid.  To renew an existing certificate,
-  operator completes the manual authentication (approving or denying
+the client uses the RenewalReq message (see Section 3.3) and signs it
-  the request).  The frequency of the polling operation is a CA/client
+with the existing client certificate.  The client SHOULD use a new
-  configuration issue and may range from seconds or minutes when the
+keypair when requesting a new certificate but MAY request a new
-  issue process is automatic but not instantaneous, through to hours or
+certificate using the old keypair.
-  days if the certificate-issue operation requires manual approval.
-  If polling mode is being used, then the client will send a single
+If the CA returns a CertRep message (Section 3.3.2) with status set
-  PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more
+to PENDING, the client enters into polling mode by periodically
-  CertPoll messages (Section 3.3.3).  The CA will, in return, send 0 or
+sending a CertPoll message (Section 3.3.3) to the CA until the CA
-  more CertRep messages (Section 3.3.2) with status set to PENDING in
+operator completes the manual authentication (approving or denying
-  response to CertPolls, followed by a single CertRep message
+the request).  The frequency of the polling operation is a CA/client
-  (Section 3.3.2) with status set to either SUCCESS or FAILURE.
+configuration 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 operation requires manual approval.
-.5.1.  Client State Transitions
+If polling mode is being used, then the client will send a single
+PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more
+CertPoll messages (Section 3.3.3).  The CA will, in return, send 0 or
+more CertRep messages (Section 3.3.2) with status set to PENDING in
+response to CertPolls, followed by a single CertRep message
+(Section 3.3.2) with status set to either SUCCESS or FAILURE.
-  The client state transitions during the SCEP process are indicated in
+==== Client State Transitions ====
-  Figure 1.
-                                  CertPoll
+The client state transitions during the SCEP process are indicated in
-                                +-----<----+
+Figure 1.
-                                |          |
-                                |          | CertRep(PENDING)
-                                |          |
-  [CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] --------> [CERT-ISSUED]
-        ^            PKCSReq    |          CertRep(SUCCESS)
-        |          RenewalReq  |
-        |                      |
-        +-----------------------+
-        CertRep(FAILURE) or
-        Max-time/max-polls exceeded
-                    Figure 1: State Transition Diagram
+                                CertPoll
+                              +-----<----+
+                              |          |
+                              |          | CertRep(PENDING)
+                              |          |
+[CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] --------> [CERT-ISSUED]
+      ^            PKCSReq    |          CertRep(SUCCESS)
+      |          RenewalReq  |
+      |                      |
+      +-----------------------+
+      CertRep(FAILURE) or
+      Max-time/max-polls exceeded
-  The certificate-issue process starts at state CERT-NONEXISTENT.
+                  Figure 1: State Transition Diagram
-  Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ-
-  PENDING.
-  If the CA returns a CertRep message with pkiStatus set to SUCCESS,
+The certificate-issue process starts at state CERT-NONEXISTENT.
-  then the state changes to CERT-ISSUED.
+Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ-
+PENDING.
-  If the CA returns a CertRep message with pkiStatus set to FAILURE or
+If the CA returns a CertRep message with pkiStatus set to SUCCESS,
-  there is no response, then the state reverts back to CERT-
+then the state changes to CERT-ISSUED.
-  NONEXISTENT.
-  If the CA returns a CertRep message with pkiStatus set to PENDING,
+If the CA returns a CertRep message with pkiStatus set to FAILURE or
-  then the client will keep polling by sending a CertPoll message until
+there is no response, then the state reverts back to CERT-
-  either a CertRep message with status set to SUCCESS or FAILURE is
+NONEXISTENT.
-  received, a timeout occurs, or the maximum number of polls has been
-  exceeded.
-  Figure 2 shows a successful transaction in automatic mode
+If the CA returns a CertRep message with pkiStatus set to PENDING,
+then the client will keep polling by sending a CertPoll message until
+either a CertRep message with status set to SUCCESS or FAILURE is
+received, a timeout occurs, or the maximum number of polls has been
+exceeded.
-      CLIENT                              CA SERVER
+Figure 2 shows a successful transaction in automatic mode
-  PKCSReq: PKI cert. enrolment message
+    CLIENT                              CA SERVER
-  --------------------------------> CertRep: pkiStatus = SUCCESS
-                                    Certificate attached
-                                    <------------------------------
-  Receive issued certificate.
-                          Figure 2: Automatic Mode
+PKCSReq: PKI cert. enrolment message
+--------------------------------> CertRep: pkiStatus = SUCCESS
+                                  Certificate attached
+                                  <------------------------------
+Receive issued certificate.
-  Figure 3 shows a successful transaction in manual mode:
+                      Figure 2: Automatic Mode
-      CLIENT                              CA SERVER
+Figure 3 shows a successful transaction in manual mode:
-  PKCSReq: PKI cert. enrolment message
+    CLIENT                              CA SERVER
-  --------------------------------> CertRep: pkiStatus = PENDING
-                                    <------------------------------
-  CertPoll: Polling message
-  --------------------------------> CertRep: pkiStatus = PENDING
-                                    <------------------------------
-  ................ <Manual identity authentication> ...............
-  CertPoll: Polling message
+PKCSReq: PKI cert. enrolment message
-  --------------------------------> CertRep: pkiStatus = SUCCESS
+--------------------------------> CertRep: pkiStatus = PENDING
-                                    Certificate attached
+                                  <------------------------------
-                                    <------------------------------
+CertPoll: Polling message
-  Receive issued certificate.
+--------------------------------> CertRep: pkiStatus = PENDING
+                                  <------------------------------
-                          Figure 3: Manual Mode
+CertPoll: Polling message
+--------------------------------> CertRep: pkiStatus = SUCCESS
+                                  Certificate attached
+                                  <------------------------------
+Receive issued certificate.
-.6.  Certificate Access
+                        Figure 3: Manual Mode
-  A certificate query message is defined for clients to retrieve a copy
+=== Certificate Access ===
-  of their own certificate from the CA.  It allows clients that do not
-  store their certificates locally to obtain a copy when needed.  This
-  functionality is not intended to provide a general-purpose
-  certificate-access service, which may be achieved instead via HTTP
-  certificate-store access [RFC4387] or Lightweight Directory Access
-  Protocol (LDAP).
-  To retrieve a certificate from the CA, a client sends a request
+A certificate query message is defined for clients to retrieve a copy
-  consisting of the certificate's issuer name and serial number.  This
+of their own certificate from the CA.  It allows clients that do not
-  assumes that the client has saved the issuer name and the serial
+store their certificates locally to obtain a copy when needed.  This
-  number of the issued certificate from the previous enrolment
+functionality is not intended to provide a general-purpose
-  transaction.  The transaction to retrieve a certificate consists of
+certificate-access service, which may be achieved instead via HTTP
-  one GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2)
+certificate-store access [[RFC4387]] or Lightweight Directory Access
-  message, as shown in Figure 4.
+Protocol (LDAP).
-      CLIENT                              CA SERVER
+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 (Section 3.3.4) message and one CertRep (Section 3.3.2)
+message, as shown in Figure 4.
-   GetCert: PKI certificate query message
+   CLIENT                              CA SERVER
-  -------------------------------> CertRep: pkiStatus = SUCCESS
-                                    Certificate attached
-                                    <-----------------------------
-  Receive the certificate.
-                    Figure 4: Retrieving a Certificate
+GetCert: PKI certificate query message
+-------------------------------> CertRep: pkiStatus = SUCCESS
+                                Certificate attached
+                                <-----------------------------
+Receive the certificate.
-.7.  CRL Access
+                  Figure 4: Retrieving a Certificate
-  SCEP clients MAY request a CRL via one of three methods:
+=== CRL Access ===
-.  If the CA supports the CRL Distribution Points (CRLDPs) extension
+SCEP clients MAY request a CRL via one of three methods:
-      [RFC5280] in issued certificates, then the CRL MAY be retrieved
-      via the mechanism specified in the CRLDP.
-.  If the CA supports HTTP certificate-store access [RFC4387], then
+.  If the CA supports the CRL Distribution Points (CRLDPs) extension
-      the CRL MAY be retrieved via the AuthorityInfoAcces [RFC5280]
+    [[RFC5280]] in issued certificates, then the CRL MAY be retrieved
-      location specified in the certificate.
+    via the mechanism specified in the CRLDP.
-.  Only if the CA does not support CRLDPs or HTTP access should a
+.  If the CA supports HTTP certificate-store access [[RFC4387]], then
-      CRL query be composed by creating a GetCRL message consisting of
+    the CRL MAY be retrieved via the AuthorityInfoAcces [[RFC5280]]
-      the issuer name and serial number from the certificate whose
+    location specified in the certificate.
-      revocation status is being queried.
-  The message is sent to the SCEP CA in the same way as the other SCEP
+.  Only if the CA does not support CRLDPs or HTTP access should a
-  requests.  The transaction to retrieve a CRL consists of one GetCRL
+    CRL query be composed by creating a GetCRL message consisting of
-  PKI message and one CertRep PKI message, which contains only the CRL
+    the issuer name and serial number from the certificate whose
-  (no certificates) in a degenerate certificates-only CMS SignedData
+    revocation status is being queried.
-  message (Section 3.4), as shown in Figure 5.
-          CLIENT                          CA SERVER
+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 SignedData
+message (Section 3.4), as shown in Figure 5.
-      GetCRL: PKI CRL query message
+      CLIENT                          CA SERVER
-  ---------------------------------->
-                                    CertRep: CRL attached
-                                    <-----------------------------
-  Receive the CRL
-                        Figure 5: Retrieving a CRL
+  GetCRL: PKI CRL query message
+---------------------------------->
+                                  CertRep: CRL attached
+                                  <-----------------------------
+Receive the CRL
-.8.  Certificate Revocation
+                      Figure 5: Retrieving a CRL
-  SCEP does not specify a method to request certificate revocation.  In
+=== Certificate Revocation ===
-  order to revoke a certificate, the client must contact the CA using a
-  non-SCEP-defined mechanism.
-.9.  Mandatory-to-Implement Functionality
+SCEP does not specify a method to request certificate revocation.  In
+order to revoke a certificate, the client must contact the CA using a
+non-SCEP-defined mechanism.
-  At a minimum, all SCEP implementations compliant with this
+=== Mandatory-to-Implement Functionality ===
-  specification MUST support GetCACaps (Section 3.5.1), GetCACert
-  (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response
-  messages), communication of binary data via HTTP POST (Section 4.1),
-  and the AES128-CBC [AES] and SHA-256 [SHA2] algorithms to secure
-  pkiMessages (Section 3.2).
-  For historical reasons, implementations MAY support communications of
+At a minimum, all SCEP implementations compliant with this
-  binary data via HTTP GET (Section 4.1), and the triple DES-CBC and
+specification MUST support GetCACaps (Section 3.5.1), GetCACert
-  SHA-1 algorithms to secure pkiMessages (Section 3.2).
+(Section 4.2), PKCSReq (Section 3.3.1) (and its associated response
-  Implementations MUST NOT support the obsolete and/or insecure single
+messages), communication of binary data via HTTP POST (Section 4.1),
-  DES and MD5 algorithms used in earlier versions of this
+and the AES128-CBC [AES] and SHA-256 [SHA2] algorithms to secure
-  specification, since the unsecured nature of GetCACaps means that an
+pkiMessages (Section 3.2).
-  in-path attacker can trivially roll back the encryption used to these
-  insecure algorithms; see Section 7.5.
-.  SCEP Secure Message Objects
+For historical reasons, implementations MAY support communications of
+binary data via HTTP GET (Section 4.1), and the triple DES-CBC and
+SHA-1 algorithms to secure pkiMessages (Section 3.2).
+Implementations MUST NOT support the obsolete and/or insecure single
+DES and MD5 algorithms used in earlier versions of this
+specification, since the unsecured nature of GetCACaps means that an
+in-path attacker can trivially roll back the encryption used to these
+insecure algorithms; see Section 7.5.
-  CMS is a general enveloping mechanism that enables both signed and
+== SCEP Secure Message Objects ==
-  encrypted transmission of arbitrary data.  SCEP messages that require
-  confidentiality use two layers of CMS, as shown using ASN.1-like
-  pseudocode in Figure 6.  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.
-  pkiMessage {
+CMS is a general enveloping mechanism that enables both signed and
-    contentType = signedData { pkcs-7 2 },
+encrypted transmission of arbitrary data.  SCEP messages that require
-    content {
+confidentiality use two layers of CMS, as shown using ASN.1-like
-      digestAlgorithms,
+pseudocode in Figure 6.  By applying both enveloping and signing
-      encapsulatedContentInfo {
+transformations, the SCEP message is protected both for the integrity
-        eContentType = data { pkcs-7 1 },
+of its end-to-end transaction information and the confidentiality of
-        eContent {          -- pkcsPKIEnvelope, optional
+its information portion.
-          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
-        }
-      }
-    }
-                          Figure 6: CMS Layering
+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
+      }
+    }
+  }
-  When a particular SCEP message carries data, this data is carried in
+                        Figure 6: CMS Layering
-  the messageData.  CertRep messages will lack any signed content and
-  consist only of a pkcsPKIEnvelope (Section 3.2.2).
-  The remainder of this document will refer only to "messageData", but
+When a particular SCEP message carries data, this data is carried in
-  it is understood to always be encapsulated in the pkcsPKIEnvelope
+the messageData.  CertRep messages will lack any signed content and
-  (Section 3.2.2).  The format of the data in the messageData is
+consist only of a pkcsPKIEnvelope (Section 3.2.2).
-  defined by the messageType attribute (see Section 3.2) of the
-  SignedData.  If there is no messageData to be transmitted, the entire
-  pkcsPKIEnvelope MUST be omitted.
-  Samples of SCEP messages are available through the JSCEP project
+The remainder of this document will refer only to "messageData", but
-  [JSCEP] in the src/samples directory.
+it is understood to always be encapsulated in the pkcsPKIEnvelope
+(Section 3.2.2).  The format of the data in the messageData is
+defined by the messageType attribute (see Section 3.2) of the
+SignedData.  If there is no messageData to be transmitted, the entire
+pkcsPKIEnvelope MUST be omitted.
-.1.  SCEP Message Object Processing
+Samples of SCEP messages are available through the JSCEP project
+[JSCEP] in the src/samples directory.
-  Creating a SCEP message consists of several stages.  The content to
+=== SCEP Message Object Processing ===
-  be conveyed (in other words, the messageData) is first encrypted, and
-  the encrypted content is then signed.
-  The form of encryption to be applied depends on the capabilities of
+Creating a SCEP message consists of several stages.  The content to
-  the recipient's public key.  If the key is encryption capable (for
+be conveyed (in other words, the messageData) is first encrypted, and
-  example, RSA), then the messageData is encrypted using the
+the encrypted content is then signed.
-  recipient's public key with the CMS KeyTransRecipientInfo mechanism.
-  If the key is not encryption capable (for example, DSA or ECDSA),
-  then the messageData is encrypted using the challengePassword with
-  the CMS PasswordRecipientInfo mechanism.
-  Once the messageData has been encrypted, it is signed with the
+The form of encryption to be applied depends on the capabilities of
-  sender's public key.  This completes the SCEP message, which is then
+the recipient's public key.  If the key is encryption capable (for
-  sent to the recipient.
+example, RSA), then the messageData is encrypted using the
+recipient's public key with the CMS KeyTransRecipientInfo mechanism.
+If the key is not encryption capable (for example, DSA or ECDSA),
+then the messageData is encrypted using the challengePassword with
+the CMS PasswordRecipientInfo mechanism.
-  Note that some early implementations of this specification dealt with
+Once the messageData has been encrypted, it is signed with the
-  keys that were not encryption capable by omitting the encryption
+sender's public key.  This completes the SCEP message, which is then
-  stage, based on the text in Section 3 that indicated that "the
+sent to the recipient.
-  EnvelopedData is omitted".  This alternative processing mechanism
-  SHOULD NOT be used since it exposes in cleartext the
-  challengePassword used to authorise the certificate issue.
+Note that some early implementations of this specification dealt with
+keys that were not encryption capable by omitting the encryption
+stage, based on the text in Section 3 that indicated that "the
+EnvelopedData is omitted".  This alternative processing mechanism
+SHOULD NOT be used since it exposes in cleartext the
+challengePassword used to authorise the certificate issue.
-.2.  SCEP pkiMessage
+=== SCEP pkiMessage ===
-  The basic building block of all secured SCEP messages is the SCEP
+The basic building block of all secured SCEP messages is the SCEP
-  pkiMessage.  It consists of a CMS SignedData content type.  The
+pkiMessage.  It consists of a CMS SignedData content type.  The
-  following restrictions apply:
+following restrictions apply:
-  *  The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7
+*  The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7
 }).
-  *  The signed content, if present (FAILURE and PENDING CertRep
+*  The signed content, if present (FAILURE and PENDING CertRep
-      messages will lack any signed content), MUST be a pkcsPKIEnvelope
+  messages will lack any signed content), MUST be a pkcsPKIEnvelope
-      (Section 3.2.2) and MUST match the messageType attribute.
+  (Section 3.2.2) and MUST match the messageType attribute.
-  *  The SignerInfo MUST contain a set of authenticatedAttributes
+*  The SignerInfo MUST contain a set of authenticatedAttributes
-      (Section 3.2.1).
+  (Section 3.2.1).
-.2.1.  Signed Transaction Attributes
+==== Signed Transaction Attributes ====
-  At a minimum, all messages MUST contain the following
+At a minimum, all messages MUST contain the following
-  authenticatedAttributes:
+authenticatedAttributes:
-  *  A transactionID attribute (see Section 3.2.1.1).
+*  A transactionID attribute (see Section 3.2.1.1).
-  *  A messageType attribute (see Section 3.2.1.2).
+*  A messageType attribute (see Section 3.2.1.2).
-  *  A fresh senderNonce attribute (see Section 3.2.1.5).  However,
+*  A fresh senderNonce attribute (see Section 3.2.1.5).  However,
-      note the comment about senderNonces and polling in Section 3.3.2
+  note the comment about senderNonces and polling in Section 3.3.2
-  *  Any attributes required by CMS.
+*  Any attributes required by CMS.
-  If the message is a CertRep, it MUST also include the following
+If the message is a CertRep, it MUST also include the following
-  authenticatedAttributes:
+authenticatedAttributes:
-  *  A pkiStatus attribute (see Section 3.2.1.3).
+*  A pkiStatus attribute (see Section 3.2.1.3).
-  *  failInfo and optional failInfoText attributes (see
+*  failInfo and optional failInfoText attributes (see
-      Section 3.2.1.4) if pkiStatus = FAILURE.
+  Section 3.2.1.4) if pkiStatus = FAILURE.
-  *  A recipientNonce attribute (see Section 3.2.1.5) copied from the
+*  A recipientNonce attribute (see Section 3.2.1.5) copied from the
-      senderNonce in the request that this is a response to.
+  senderNonce in the request that this is a response to.
-  The following transaction attributes are encoded as authenticated
+The following transaction attributes are encoded as authenticated
-  attributes and carried in the SignerInfo for this SignedData.
+attributes and carried in the SignerInfo for this SignedData.
-  +================+=================+==============================+
++================+=================+==============================+
-  | Attribute      | Encoding        | Comment                      |
+| Attribute      | Encoding        | Comment                      |
-  +================+=================+==============================+
++================+=================+==============================+
-  | transactionID  | PrintableString | Unique ID for this          |
+| transactionID  | PrintableString | Unique ID for this          |
-  |                |                | transaction as a text string |
+|                |                | transaction as a text string |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | messageType    | PrintableString | Decimal value as a numeric  |
+| messageType    | PrintableString | Decimal value as a numeric  |
-  |                |                | text string                  |
+|                |                | text string                  |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | pkiStatus      | PrintableString | Decimal value as a numeric  |
+| pkiStatus      | PrintableString | Decimal value as a numeric  |
-  |                |                | text string                  |
+|                |                | text string                  |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | failInfo      | PrintableString | Decimal value as a numeric  |
+| failInfo      | PrintableString | Decimal value as a numeric  |
-  |                |                | text string                  |
+|                |                | text string                  |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | failInfoText  | UTF8String      | Descriptive text for the    |
+| failInfoText  | UTF8String      | Descriptive text for the    |
-  |                |                | failInfo value              |
+|                |                | failInfo value              |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | senderNonce    | OCTET STRING    | Random nonce as a 16-byte    |
+| senderNonce    | OCTET STRING    | Random nonce as a 16-byte    |
-  |                |                | binary data string          |
+|                |                | binary data string          |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-  | recipientNonce | OCTET STRING    | Random nonce as a 16-byte    |
+| recipientNonce | OCTET STRING    | Random nonce as a 16-byte    |
-  |                |                | binary data string          |
+|                |                | binary data string          |
-  +----------------+-----------------+------------------------------+
++----------------+-----------------+------------------------------+
-                        Table 1: SCEP Attributes
+                      Table 1: SCEP Attributes
-  The OIDs used for these attributes are as follows:
+The OIDs used for these attributes are as follows:
-  +======================+===============================+
++======================+===============================+
-  | Name                | ASN.1 Definition              |
+| Name                | ASN.1 Definition              |
-  +======================+===============================+
++======================+===============================+
-  | id-VeriSign          | OBJECT_IDENTIFIER ::= {2 16  |
+| id-VeriSign          | OBJECT_IDENTIFIER ::= {2 16  |
-  |                      | US(840) 1 VeriSign(113733)}  |
+|                      | US(840) 1 VeriSign(113733)}  |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-pki              | OBJECT_IDENTIFIER ::= {id-    |
+| id-pki              | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | VeriSign pki(1)}              |
+|                      | VeriSign pki(1)}              |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-attributes        | OBJECT_IDENTIFIER ::= {id-pki |
+| id-attributes        | OBJECT_IDENTIFIER ::= {id-pki |
-  |                      | attributes(9)}                |
+|                      | attributes(9)}                |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-transactionID    | OBJECT_IDENTIFIER ::= {id-    |
+| id-transactionID    | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes transactionID(7)}  |
+|                      | attributes transactionID(7)}  |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-messageType      | OBJECT_IDENTIFIER ::= {id-    |
+| id-messageType      | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes messageType(2)}    |
+|                      | attributes messageType(2)}    |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-pkiStatus        | OBJECT_IDENTIFIER ::= {id-    |
+| id-pkiStatus        | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes pkiStatus(3)}      |
+|                      | attributes pkiStatus(3)}      |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-failInfo          | OBJECT_IDENTIFIER ::= {id-    |
+| id-failInfo          | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes failInfo(4)}      |
+|                      | attributes failInfo(4)}      |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-senderNonce      | OBJECT_IDENTIFIER ::= {id-    |
+| id-senderNonce      | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes senderNonce(5)}    |
+|                      | attributes senderNonce(5)}    |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-recipientNonce    | OBJECT_IDENTIFIER ::= {id-    |
+| id-recipientNonce    | OBJECT_IDENTIFIER ::= {id-    |
-  |                      | attributes recipientNonce(6)} |
+|                      | attributes recipientNonce(6)} |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-scep              | OBJECT IDENTIFIER ::= {id-    |
+| id-scep              | OBJECT IDENTIFIER ::= {id-    |
-  |                      | pkix 24}                      |
+|                      | pkix 24}                      |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-  | id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-    |
+| id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-    |
-  |                      | scep 1}                      |
+|                      | scep 1}                      |
-  +----------------------+-------------------------------+
++----------------------+-------------------------------+
-                Table 2: SCEP Attribute OIDs
+              Table 2: SCEP Attribute OIDs
-  The attributes are detailed in the following sections.
+The attributes are detailed in the following sections.
-.2.1.1.  transactionID
+===== transactionID =====
-  A PKI operation is a transaction consisting of the messages exchanged
+A PKI operation is a transaction consisting of the messages exchanged
-  between a client and the CA.  The transactionID is a text string
+between a client and the CA.  The transactionID is a text string
-  provided by the client when starting a transaction.  The client MUST
+provided by the client when starting a transaction.  The client MUST
-  use a unique string as the transaction identifier, encoded as a
+use a unique string as the transaction identifier, encoded as a
-  PrintableString, which MUST be used for all PKI messages exchanged
+PrintableString, which MUST be used for all PKI messages exchanged
-  for a given operation, such as a certificate issue.
+for a given operation, such as a certificate issue.
-  Note that the transactionID must be unique, but not necessarily
+Note that the transactionID must be unique, but not necessarily
-  randomly generated.  For example, it may be a value assigned by the
+randomly generated.  For example, it may be a value assigned by the
-  CA to allow the client to be identified by their transactionID, using
+CA to allow the client to be identified by their transactionID, using
-  a value such as the client device's Extended Unique Identifier (EUI),
+a value such as the client device's Extended Unique Identifier (EUI),
-  Remote Terminal Unit (RTU) ID, or a similar unique identifier.  This
+Remote Terminal Unit (RTU) ID, or a similar unique identifier.  This
-  can be useful when the client doesn't have a preassigned
+can be useful when the client doesn't have a preassigned
-  Distinguished Name through which the CA can identify their request --
+Distinguished Name through which the CA can identify their request --
-  for example, when enrolling Supervisory Control and Data Acquisition
+for example, when enrolling Supervisory Control and Data Acquisition
-  (SCADA) devices.
+(SCADA) devices.
-.2.1.2.  messageType
+===== messageType =====
-  The messageType attribute specifies the type of operation performed
+The messageType attribute specifies the type of operation performed
-  by the transaction.  This attribute MUST be included in all PKI
+by the transaction.  This attribute MUST be included in all PKI
-  messages.  The following message types are defined:
+messages.  The following message types are defined:
-    +=======+============+============================================+
+ +=======+============+============================================+
-    | Value | Name      | Description                                |
+ | Value | Name      | Description                                |
-    +=======+============+============================================+
+ +=======+============+============================================+
-    | 0    | Reserved  |                                            |
+ | 0    | Reserved  |                                            |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 3    | CertRep    | Response to certificate or CRL request.    |
+ | 3    | CertRep    | Response to certificate or CRL request.    |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 17    | RenewalReq | PKCS #10 certificate request authenticated |
+ | 17    | RenewalReq | PKCS #10 certificate request authenticated |
-    |      |            | with an existing certificate.              |
+ |      |            | with an existing certificate.              |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 19    | PKCSReq    | PKCS #10 certificate request authenticated |
+ | 19    | PKCSReq    | PKCS #10 certificate request authenticated |
-    |      |            | with a shared secret.                      |
+ |      |            | with a shared secret.                      |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 20    | CertPoll  | Certificate polling in manual enrolment.  |
+ | 20    | CertPoll  | Certificate polling in manual enrolment.  |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 21    | GetCert    | Retrieve a certificate.                    |
+ | 21    | GetCert    | Retrieve a certificate.                    |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-    | 22    | GetCRL    | Retrieve a CRL.                            |
+ | 22    | GetCRL    | Retrieve a CRL.                            |
-    +-------+------------+--------------------------------------------+
+ +-------+------------+--------------------------------------------+
-                        Table 3: SCEP Message Types
+                    Table 3: SCEP Message Types
-  Message types not defined above MUST be treated as errors unless
+Message types not defined above MUST be treated as errors unless
-  their use has been negotiated through GetCACaps (Section 3.5.1).
+their use has been negotiated through GetCACaps (Section 3.5.1).
-.2.1.3.  pkiStatus
+===== pkiStatus =====
-  All response messages MUST include transaction status information,
+All response messages MUST include transaction status information,
-  which is defined as a pkiStatus attribute:
+which is defined as a pkiStatus attribute:
-      +=======+=========+========================================+
+    +=======+=========+========================================+
-      | Value | Name    | Description                            |
+    | Value | Name    | Description                            |
-      +=======+=========+========================================+
+    +=======+=========+========================================+
-      | 0    | SUCCESS | Request granted.                      |
+    | 0    | SUCCESS | Request granted.                      |
-      +-------+---------+----------------------------------------+
+    +-------+---------+----------------------------------------+
-      | 2    | FAILURE | Request rejected.  In this case, the  |
+    | 2    | FAILURE | Request rejected.  In this case, the  |
-      |      |        | failInfo attribute, as defined in      |
+    |      |        | failInfo attribute, as defined in      |
-      |      |        | Section 3.2.1.4, MUST also be present. |
+    |      |        | Section 3.2.1.4, MUST also be present. |
-      +-------+---------+----------------------------------------+
+    +-------+---------+----------------------------------------+
-      | 3    | PENDING | Request pending for manual approval.  |
+    | 3    | PENDING | Request pending for manual approval.  |
-      +-------+---------+----------------------------------------+
+    +-------+---------+----------------------------------------+
-                      Table 4: pkiStatus Attributes
+                  Table 4: pkiStatus Attributes
-  PKI status values not defined above MUST be treated as errors unless
+PKI status values not defined above MUST be treated as errors unless
-  their use has been negotiated through GetCACaps (Section 3.5.1).
+their use has been negotiated through GetCACaps (Section 3.5.1).
-.2.1.4.  failInfo and failInfoText
+===== failInfo and failInfoText =====
-  The failInfo attribute MUST contain one of the following failure
+The failInfo attribute MUST contain one of the following failure
-  reasons:
+reasons:
-      +=======+=================+==================================+
+  +=======+=================+==================================+
-      | Value | Name            | Description                      |
+  | Value | Name            | Description                      |
-      +=======+=================+==================================+
+  +=======+=================+==================================+
-      | 0    | badAlg          | Unrecognised or unsupported      |
+  | 0    | badAlg          | Unrecognised or unsupported      |
-      |      |                | algorithm.                      |
+  |      |                | algorithm.                      |
-      +-------+-----------------+----------------------------------+
+  +-------+-----------------+----------------------------------+
-      | 1    | badMessageCheck | Integrity check (meaning        |
+  | 1    | badMessageCheck | Integrity check (meaning        |
-      |      |                | signature verification of the    |
+  |      |                | signature verification of the    |
-      |      |                | CMS message) failed.            |
+  |      |                | CMS message) failed.            |
-      +-------+-----------------+----------------------------------+
+  +-------+-----------------+----------------------------------+
-      | 2    | badRequest      | Transaction not permitted or    |
+  | 2    | badRequest      | Transaction not permitted or    |
-      |      |                | supported.                      |
+  |      |                | supported.                      |
-      +-------+-----------------+----------------------------------+
+  +-------+-----------------+----------------------------------+
-      | 3    | badTime        | The signingTime attribute from  |
+  | 3    | badTime        | The signingTime attribute from  |
-      |      |                | the CMS authenticatedAttributes  |
+  |      |                | the CMS authenticatedAttributes  |
-      |      |                | was not sufficiently close to    |
+  |      |                | was not sufficiently close to    |
-      |      |                | the system time.  This condition |
+  |      |                | the system time.  This condition |
-      |      |                | may occur if the CA is concerned |
+  |      |                | may occur if the CA is concerned |
-      |      |                | about replays of old messages.  |
+  |      |                | about replays of old messages.  |
-      +-------+-----------------+----------------------------------+
+  +-------+-----------------+----------------------------------+
-      | 4    | badCertId      | No certificate could be          |
+  | 4    | badCertId      | No certificate could be          |
-      |      |                | identified matching the provided |
+  |      |                | identified matching the provided |
-      |      |                | criteria.                        |
+  |      |                | criteria.                        |
-      +-------+-----------------+----------------------------------+
+  +-------+-----------------+----------------------------------+
-                      Table 5: failInfo Attributes
+                    Table 5: failInfo Attributes
-  Failure reasons not defined above MUST be treated as errors unless
+Failure reasons not defined above MUST be treated as errors unless
-  their use has been negotiated through GetCACaps (Section 3.5.1).
+their use has been negotiated through GetCACaps (Section 3.5.1).
-  The failInfoText is a free-form UTF-8 text string that provides
+The failInfoText is a free-form UTF-8 text string that provides
-  further information in the case of pkiStatus = FAILURE.  In
+further information in the case of pkiStatus = FAILURE.  In
-  particular, it may be used to provide details on why a certificate
+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-
+request was not granted that go beyond what's provided by the near-
-  universal failInfo = badRequest status.  Since this is a free-form
+universal failInfo = badRequest status.  Since this is a free-form
-  text string intended for interpretation by humans, implementations
+text string intended for interpretation by humans, implementations
-  SHOULD NOT assume that it has any type of machine-processable
+SHOULD NOT assume that it has any type of machine-processable
-  content.
+content.
-.2.1.5.  senderNonce and recipientNonce
+===== senderNonce and recipientNonce =====
-  The senderNonce and recipientNonce attributes are each a 16-byte
+The senderNonce and recipientNonce attributes are each a 16-byte
-  random number generated for each transaction.  These are intended to
+random number generated for each transaction.  These are intended to
-  prevent replay attacks.
+prevent replay attacks.
-  When a sender sends a PKI message to a recipient, a fresh senderNonce
+When a sender sends a PKI message to a recipient, a fresh senderNonce
-  MUST be included in the message.  The recipient MUST copy the
+MUST be included in the message.  The recipient MUST copy the
-  senderNonce into the recipientNonce of the reply as a proof of
+senderNonce into the recipientNonce of the reply as a proof of
-  liveliness.  The original sender MUST verify that the recipientNonce
+liveliness.  The original sender MUST verify that the recipientNonce
-  of the reply matches the senderNonce it sent in the request.  If the
+of the reply matches the senderNonce it sent in the request.  If the
-  nonce does not match, then the message MUST be rejected.
+nonce does not match, then the message MUST be rejected.
-  Note that since SCEP exchanges consist of a single request followed
+Note that since SCEP exchanges consist of a single request followed
-  by a single response, the use of distinct sender and recipient nonces
+by a single response, the use of distinct sender and recipient nonces
-  is redundant, since the client sends a nonce in its request and the
+is redundant, since the client sends a nonce in its request and the
-  CA responds with the same nonce in its reply.  In effect, there's
+CA responds with the same nonce in its reply.  In effect, there's
-  just a single nonce, identified as senderNonce in the client's
+just a single nonce, identified as senderNonce in the client's
-  request and recipientNonce in the CA's reply.
+request and recipientNonce in the CA's reply.
-.2.2.  SCEP pkcsPKIEnvelope
+==== SCEP pkcsPKIEnvelope ====
-  The information portion of a SCEP message is carried inside an
+The information portion of a SCEP message is carried inside an
-  EnvelopedData content type, as defined in CMS, with the following
+EnvelopedData content type, as defined in CMS, with the following
-  restrictions:
+restrictions:
-  *  contentType in encryptedContentInfo MUST be data ({pkcs-7 1}).
+*  contentType in encryptedContentInfo MUST be data ({pkcs-7 1}).
-  *  encryptedContent MUST be the SCEP message being transported (see
+*  encryptedContent MUST be the SCEP message being transported (see
-      Section 4) and MUST match the messageType authenticated Attribute
+  Section 4) and MUST match the messageType authenticated Attribute
-      in the pkiMessage.
+  in the pkiMessage.
-.3.  SCEP pkiMessage types
+=== SCEP pkiMessage types ===
-  All of the messages in this section are pkiMessages (Section 3.2),
+All of the messages in this section are pkiMessages (Section 3.2),
-  where the type of the message MUST be specified in the "messageType"
+where the type of the message MUST be specified in the "messageType"
-  authenticated Attribute.  Each section defines a valid message type,
+authenticated Attribute.  Each section defines a valid message type,
-  the corresponding messageData formats, and mandatory authenticated
+the corresponding messageData formats, and mandatory authenticated
-  attributes for that type.
+attributes for that type.
-.3.1.  PKCSReq/RenewalReq
+==== PKCSReq/RenewalReq ====
-  The messageData for this type consists of a PKCS #10 Certificate
+The messageData for this type consists of a PKCS #10 Certificate
-  Request.  The certificate request MUST contain at least the following
+Request.  The certificate request MUST contain at least the following
-  items:
+items:
-  *  The subject Distinguished Name.
+*  The subject Distinguished Name.
-  *  The subject public key.
+*  The subject public key.
-  *  For a PKCSReq, if authorisation based on a shared secret is being
+*  For a PKCSReq, if authorisation based on a shared secret is being
-      used, a challengePassword attribute.
+  used, a challengePassword attribute.
-  In addition, the message must contain the authenticatedAttributes
+In addition, the message must contain the authenticatedAttributes
-  specified in Section 3.2.1.
+specified in Section 3.2.1.
-.3.2.  CertRep
+==== CertRep ====
-  The messageData for this type consists of a degenerate certificates-
+The messageData for this type consists of a degenerate certificates-
-  only CMS SignedData message (Section 3.4).  The exact content
+only CMS SignedData message (Section 3.4).  The exact content
-  required for the reply depends on the type of request that this
+required for the reply depends on the type of request that this
-  message is a response to.  The request types are detailed in Sections
+message is a response to.  The request types are detailed in Sections
 .3.2.1 and 4.  In addition, the message must contain the
-  authenticatedAttributes specified in Section 3.2.1.
+authenticatedAttributes specified in Section 3.2.1.
-  Earlier draft versions of this specification required that this
+Earlier draft versions of this specification required that this
-  message include a senderNonce alongside the recipientNonce, which was
+message include a senderNonce alongside the recipientNonce, which was
-  to be used to chain to subsequent polling operations.  However, if a
+to be used to chain to subsequent polling operations.  However, if a
-  single message was lost during the potentially extended interval over
+single message was lost during the potentially extended interval over
-  which polling could take place (see Section 5 for an example of
+which polling could take place (see Section 5 for an example of
-  this), then if the implementation were to enforce this requirement,
+this), then if the implementation were to enforce this requirement,
-  the overall transaction would fail, even though nothing had actually
+the overall transaction would fail, even though nothing had actually
-  gone wrong.  Because of this issue, implementations mostly ignored
+gone wrong.  Because of this issue, implementations mostly ignored
-  the requirement to either carry this nonce over to subsequent polling
+the requirement to either carry this nonce over to subsequent polling
-  messages or verify its presence.  More recent versions of the
+messages or verify its presence.  More recent versions of the
-  specification no longer require the chaining of nonces across polling
+specification no longer require the chaining of nonces across polling
-  operations.
+operations.
-.3.2.1.  CertRep SUCCESS
+===== CertRep SUCCESS =====
-  When the pkiStatus attribute is set to SUCCESS, the messageData for
+When the pkiStatus attribute is set to SUCCESS, the messageData for
-  this message consists of a degenerate certificates-only CMS
+this message consists of a degenerate certificates-only CMS
-  SignedData message (Section 3.4).  The content of this degenerate
+SignedData message (Section 3.4).  The content of this degenerate
-  certificates-only SignedData message depends on what the original
+certificates-only SignedData message depends on what the original
-  request was, as outlined in Table 6.
+request was, as outlined in Table 6.
-  +==============+===============================================+
++==============+===============================================+
-  | Request-type | Reply-contents                                |
+| Request-type | Reply-contents                                |
-  +==============+===============================================+
++==============+===============================================+
-  | PKCSReq      | The reply MUST contain at least the issued    |
+| PKCSReq      | The reply MUST contain at least the issued    |
-  |              | certificate in the certificates field of the  |
+|              | certificate in the certificates field of the  |
-  |              | SignedData.  The reply MAY contain additional |
+|              | SignedData.  The reply MAY contain additional |
-  |              | certificates, but the issued certificate MUST |
+|              | certificates, but the issued certificate MUST |
-  |              | be the leaf certificate.                      |
+|              | be the leaf certificate.                      |
-  +--------------+-----------------------------------------------+
++--------------+-----------------------------------------------+
-  | RenewalReq  | Same as PKCSReq                              |
+| RenewalReq  | Same as PKCSReq                              |
-  +--------------+-----------------------------------------------+
++--------------+-----------------------------------------------+
-  | CertPoll    | Same as PKCSReq                              |
+| CertPoll    | Same as PKCSReq                              |
-  +--------------+-----------------------------------------------+
++--------------+-----------------------------------------------+
-  | GetCert      | The reply MUST contain at least the requested |
+| GetCert      | The reply MUST contain at least the requested |
-  |              | certificate in the certificates field of the  |
+|              | certificate in the certificates field of the  |
-  |              | SignedData.  The reply MAY contain additional |
+|              | SignedData.  The reply MAY contain additional |
-  |              | certificates, but the requested certificate  |
+|              | certificates, but the requested certificate  |
-  |              | MUST be the leaf certificate.                |
+|              | MUST be the leaf certificate.                |
-  +--------------+-----------------------------------------------+
++--------------+-----------------------------------------------+
-  | GetCRL      | The reply MUST contain the CRL in the crls    |
+| GetCRL      | The reply MUST contain the CRL in the crls    |
-  |              | field of the SignedData.                      |
+|              | field of the SignedData.                      |
-  +--------------+-----------------------------------------------+
++--------------+-----------------------------------------------+
-                  Table 6: CertRep Response Types
+                Table 6: CertRep Response Types
-.3.2.2.  CertRep FAILURE
+===== CertRep FAILURE =====
-  When the pkiStatus attribute is set to FAILURE, the reply MUST also
+When the pkiStatus attribute is set to FAILURE, the reply MUST also
-  contain a failInfo (Section 3.2.1.4) attribute set to the appropriate
+contain a failInfo (Section 3.2.1.4) attribute set to the appropriate
-  error condition describing the failure.  The reply MAY also contain a
+error condition describing the failure.  The reply MAY also contain a
-  failInfoText attribute providing extended details on why the
+failInfoText attribute providing extended details on why the
-  operation failed, typically to expand on the catchall failInfo =
+operation failed, typically to expand on the catchall failInfo =
-  badRequest status.  The pkcsPKIEnvelope (Section 3.2.2) MUST be
+badRequest status.  The pkcsPKIEnvelope (Section 3.2.2) MUST be
-  omitted.
+omitted.
-.3.2.3.  CertRep PENDING
+===== CertRep PENDING =====
-  When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope
+When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope
-  (Section 3.2.2) MUST be omitted.
+(Section 3.2.2) MUST be omitted.
-.3.3.  CertPoll (GetCertInitial)
+==== CertPoll (GetCertInitial) ====
-  This message is used for certificate polling.  For unknown reasons,
+This message is used for certificate polling.  For unknown reasons,
-  it was referred to as "GetCertInitial" in earlier draft versions of
+it was referred to as "GetCertInitial" in earlier draft versions of
-  this specification.  The messageData for this type consists of an
+this specification.  The messageData for this type consists of an
-  IssuerAndSubject:
+IssuerAndSubject:
-  issuerAndSubject ::= SEQUENCE {
+issuerAndSubject ::= SEQUENCE {
-      issuer    Name,
+    issuer    Name,
-      subject    Name
+    subject    Name
-      }
+    }
-  The issuer is set to the subjectName of the CA (in other words, the
+The issuer is set to the subjectName of the CA (in other words, the
-  intended issuerName of the certificate that's being requested).  The
+intended issuerName of the certificate that's being requested).  The
-  subject is set to the subjectName used when requesting the
+subject is set to the subjectName used when requesting the
-  certificate.
+certificate.
-  Note that both of these fields are redundant; the CA is identified by
+Note that both of these fields are redundant; the CA is identified by
-  the recipientInfo in the pkcsPKIEnvelope (or in most cases, simply by
+the recipientInfo in the pkcsPKIEnvelope (or in most cases, simply by
-  the server that the message is being sent to), and the client/
+the server that the message is being sent to), and the client/
-  transaction being polled is identified by the transactionID.  Both of
+transaction being polled is identified by the transactionID.  Both of
-  these fields can be processed by the CA without going through the
+these fields can be processed by the CA without going through the
-  cryptographically expensive process of unwrapping and processing the
+cryptographically expensive process of unwrapping and processing the
-  issuerAndSubject.  For this reason, implementations SHOULD assume
+issuerAndSubject.  For this reason, implementations SHOULD assume
-  that the polling operation will be controlled by the recipientInfo
+that the polling operation will be controlled by the recipientInfo
-  and transactionID rather than the contents of the messageData.  In
+and transactionID rather than the contents of the messageData.  In
-  addition, the message must contain the authenticatedAttributes
+addition, the message must contain the authenticatedAttributes
-  specified in Section 3.2.1.
+specified in Section 3.2.1.
-.3.4.  GetCert and GetCRL
+==== GetCert and GetCRL ====
-  The messageData for these types consist of an IssuerAndSerialNumber,
+The messageData for these types consist of an IssuerAndSerialNumber,
-  as defined in CMS, that uniquely identifies the certificate being
+as defined in CMS, that uniquely identifies the certificate being
-  requested, either the certificate itself for GetCert or its
+requested, either the certificate itself for GetCert or its
-  revocation status via a CRL for GetCRL.  In addition, the message
+revocation status via a CRL for GetCRL.  In addition, the message
-  must contain the authenticatedAttributes specified in Section 3.2.1.
+must contain the authenticatedAttributes specified in Section 3.2.1.
-  These message types, while included here for completeness, apply
+These message types, while included here for completeness, apply
-  unnecessary cryptography and messaging overhead to the simple task of
+unnecessary cryptography and messaging overhead to the simple task of
-  transferring a certificate or CRL (see Section 7.8).  Implementations
+transferring a certificate or CRL (see Section 7.8).  Implementations
-  SHOULD prefer HTTP certificate-store access [RFC4387] or LDAP over
+SHOULD prefer HTTP certificate-store access [[RFC4387]] or LDAP over
-  the use of these messages.
+the use of these messages.
-.4.  Degenerate certificates-only CMS SignedData
+=== Degenerate certificates-only CMS SignedData ===
-  CMS includes a degenerate case of the SignedData content type in
+CMS includes a degenerate case of the SignedData content type in
-  which there are no signers.  The use of such a degenerate case is to
+which there are no signers.  The use of such a degenerate case is to
-  disseminate certificates and CRLs.  For SCEP, the content field of
+disseminate certificates and CRLs.  For SCEP, the content field of
-  the ContentInfo value of a degenerate certificates-only SignedData
+the ContentInfo value of a degenerate certificates-only SignedData
-  MUST be omitted.  When carrying certificates, the certificates are
+MUST be omitted.  When carrying certificates, the certificates are
-  included in the certificates field of the SignedData.  When carrying
+included in the certificates field of the SignedData.  When carrying
-  a CRL, the CRL is included in the crls field of the SignedData.
+a CRL, the CRL is included in the crls field of the SignedData.
-.5.  CA Capabilities
+=== CA Capabilities ===
-  In order to provide support for future enhancements to the protocol,
+In order to provide support for future enhancements to the protocol,
-  CAs MUST implement the GetCACaps message to allow clients to query
+CAs MUST implement the GetCACaps message to allow clients to query
-  which functionality is available from the CA.
+which functionality is available from the CA.
-.5.1.  GetCACaps HTTP Message Format
+==== GetCACaps HTTP Message Format ====
-  This message requests capabilities from a CA, with the format as
+This message requests capabilities from a CA, with the format as
-  described in Section 4.1:
+described in Section 4.1:
-  "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
+"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
-.5.2.  CA Capabilities Response Format
+==== CA Capabilities Response Format ====
-  The response for a GetCACaps message is a list of CA capabilities, in
+The response for a GetCACaps message is a list of CA capabilities, in
-  plain text and in any order, separated by <CR><LF> or <LF>
+plain text and in any order, separated by <CR><LF> or <LF>
-  characters.  This specification defines the following keywords
+characters.  This specification defines the following keywords
-  (quotation marks are not sent):
+(quotation marks are not sent):
-  +==================+========================================+
++==================+========================================+
-  | Keyword          | Description                            |
+| Keyword          | Description                            |
-  +==================+========================================+
++==================+========================================+
-  | AES              | CA supports the AES128-CBC encryption  |
+| AES              | CA supports the AES128-CBC encryption  |
-  |                  | algorithm.                            |
+|                  | algorithm.                            |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | DES3            | CA supports the triple DES-CBC        |
+| DES3            | CA supports the triple DES-CBC        |
-  |                  | encryption algorithm.                  |
+|                  | encryption algorithm.                  |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | GetNextCACert    | CA supports the GetNextCACert message. |
+| GetNextCACert    | CA supports the GetNextCACert message. |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | POSTPKIOperation | CA supports PKIOPeration messages sent |
+| POSTPKIOperation | CA supports PKIOPeration messages sent |
-  |                  | via HTTP POST.                        |
+|                  | via HTTP POST.                        |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | Renewal          | CA supports the Renewal CA operation.  |
+| Renewal          | CA supports the Renewal CA operation.  |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | SHA-1            | CA supports the SHA-1 hashing          |
+| SHA-1            | CA supports the SHA-1 hashing          |
-  |                  | algorithm.                            |
+|                  | algorithm.                            |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | SHA-256          | CA supports the SHA-256 hashing        |
+| SHA-256          | CA supports the SHA-256 hashing        |
-  |                  | algorithm.                            |
+|                  | algorithm.                            |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | SHA-512          | CA supports the SHA-512 hashing        |
+| SHA-512          | CA supports the SHA-512 hashing        |
-  |                  | algorithm.                            |
+|                  | algorithm.                            |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-  | SCEPStandard    | CA supports all mandatory-to-implement |
+| SCEPStandard    | CA supports all mandatory-to-implement |
-  |                  | sections of the SCEP standard.  This  |
+|                  | sections of the SCEP standard.  This  |
-  |                  | keyword implies "AES",                |
+|                  | keyword implies "AES",                |
-  |                  | "POSTPKIOperation", and "SHA-256", as  |
+|                  | "POSTPKIOperation", and "SHA-256", as  |
-  |                  | well as the provisions of Section 2.9. |
+|                  | well as the provisions of Section 2.9. |
-  +------------------+----------------------------------------+
++------------------+----------------------------------------+
-                Table 7: GetCACaps Response Keywords
+            Table 7: GetCACaps Response Keywords
-  Table 7 lists all of the keywords that are defined in this
+Table 7 lists all of the keywords that are defined in this
-  specification.  A CA MAY provide additional keywords advertising
+specification.  A CA MAY provide additional keywords advertising
-  further capabilities and functionality.  A client MUST be able to
+further capabilities and functionality.  A client MUST be able to
-  accept and ignore any unknown keywords that might be sent by a CA.
+accept and ignore any unknown keywords that might be sent by a CA.
-  The CA MUST use the text case specified here, but clients SHOULD
+The CA MUST use the text case specified here, but clients SHOULD
-  ignore the text case when processing this message.  Clients MUST
+ignore the text case when processing this message.  Clients MUST
-  accept the standard HTTP-style text delimited by <CR><LF> as well as
+accept the standard HTTP-style text delimited by <CR><LF> as well as
-  the text delimited by <LF> specified in an earlier draft version of
+the text delimited by <LF> specified in an earlier draft version of
-  this specification.
+this specification.
-  The client SHOULD use SHA-256 in preference to SHA-1 hashing and
+The client SHOULD use SHA-256 in preference to SHA-1 hashing and
-  AES128-CBC in preference to triple DES-CBC if they are supported by
+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
+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
+be specified, in the interests of interoperability the de facto
-  universal standards of AES128-CBC and SHA-256 SHOULD be used.
+universal standards of AES128-CBC and SHA-256 SHOULD be used.
-  Announcing some of these capabilities individually is redundant,
+Announcing some of these capabilities individually is redundant,
-  since they're required as mandatory-to-implement functionality (see
+since they're required as mandatory-to-implement functionality (see
-  Section 2.9) whose presence as a whole is signalled by the
+Section 2.9) whose presence as a whole is signalled by the
-  "SCEPStandard" capability.  However, it may be useful to announce
+"SCEPStandard" capability.  However, it may be useful to announce
-  them in order to deal with older implementations that would otherwise
+them in order to deal with older implementations that would otherwise
-  default to obsolete, insecure algorithms and mechanisms.
+default to obsolete, insecure algorithms and mechanisms.
-  If the CA supports none of the above capabilities, it SHOULD return
+If the CA supports none of the above capabilities, it SHOULD return
-  an empty message.  A CA MAY simply return an HTTP error.  A client
+an empty message.  A CA MAY simply return an HTTP error.  A client
-  that receives an empty message or an HTTP error SHOULD interpret the
+that receives an empty message or an HTTP error SHOULD interpret the
-  response as if none of the capabilities listed are supported by the
+response as if none of the capabilities listed are supported by the
-  CA.
+CA.
-  Note that at least one widely deployed server implementation supports
+Note that at least one widely deployed server implementation supports
-  several of the above operations but doesn't support the GetCACaps
+several of the above operations but doesn't support the GetCACaps
-  message to indicate that it supports them, and it will close the
+message to indicate that it supports them, and it will close the
-  connection if sent a GetCACaps message.  This means that the
+connection if sent a GetCACaps message.  This means that the
-  equivalent of GetCACaps must be performed through server
+equivalent of GetCACaps must be performed through server
-  fingerprinting, which can be done using the ID string "Microsoft-
+fingerprinting, which can be done using the ID string "Microsoft-
-  IIS".  Newer versions of the same server, if sent a SCEP request
+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
+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
+be decrypted, requiring the use of 3DES and SHA-1 in order to obtain
-  a response that can be processed, even if AES and/or SHA-2 are
+a response that can be processed, even if AES and/or SHA-2 are
-  allegedly supported.  In addition, the server will generate CA
+allegedly supported.  In addition, the server will generate CA
-  certificates that only have one, but not both, of the keyEncipherment
+certificates that only have one, but not both, of the keyEncipherment
-  and digitalSignature keyUsage flags set, requiring that the client
+and digitalSignature keyUsage flags set, requiring that the client
-  ignore the keyUsage flags in order to use the certificates for SCEP.
+ignore the keyUsage flags in order to use the certificates for SCEP.
-  The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD
+The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD
-  ignore the Content-type, as older implementations of SCEP may send
+ignore the Content-type, as older implementations of SCEP may send
-  various Content-types.
+various Content-types.
-  Example:
+Example:
-  GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1
+GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1
-  might return:
+might return:
-  AES
+AES
-  GetNextCACert
+GetNextCACert
-  POSTPKIOperation
+POSTPKIOperation
-  SCEPStandard
+SCEPStandard
-  SHA-256
+SHA-256
-  This means that the CA supports modern crypto algorithms, and the
+This means that the CA supports modern crypto algorithms, and the
-  GetNextCACert message allows PKIOperation messages (PKCSReq/
+GetNextCACert message allows PKIOperation messages (PKCSReq/
-  RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST and is
+RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST and is
-  compliant with the final version of the SCEP standard.
+compliant with the final version of the SCEP standard.
-.  SCEP Transactions
+== SCEP Transactions ==
-  This section describes the SCEP Transactions and their HTTP [RFC7230]
+This section describes the SCEP Transactions and their HTTP [[RFC7230]]
-  transport mechanism.
+transport mechanism.
-  Note that SCEP doesn't follow best current practices on usage of
+Note that SCEP doesn't follow best current practices on usage of
-  HTTP.  In particular, it recommends ignoring some media types and
+HTTP.  In particular, it recommends ignoring some media types and
-  hard-codes specific URI paths.  Guidance on the appropriate
+hard-codes specific URI paths.  Guidance on the appropriate
-  application of HTTP in these circumstances may be found in [HTTP].
+application of HTTP in these circumstances may be found in [HTTP].
-.1.  HTTP POST and GET Message Formats
+=== HTTP POST and GET Message Formats ===
-  SCEP uses the HTTP POST and GET methods [RFC7230] to exchange
+SCEP uses the HTTP POST and GET methods [[RFC7230]] to exchange
-  information with the CA.  The following defines the ABNF syntax of
+information with the CA.  The following defines the ABNF syntax of
-  HTTP POST and GET methods sent from a client to a CA:
+HTTP POST and GET methods sent from a client to a CA:
-  POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION
+POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION
-                SP HTTP-version CRLF
+              SP HTTP-version CRLF
-  GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
+GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
-                "&message=" MESSAGE SP HTTP-version CRLF
+            "&message=" MESSAGE SP HTTP-version CRLF
-  where:
+where:
-  *  SCEPPATH is the HTTP URL path for accessing the CA.  Clients
+*  SCEPPATH is the HTTP URL path for accessing the CA.  Clients
-      SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe"
+  SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe"
-      unless directed to do otherwise by the CA.
+  unless directed to do otherwise by the CA.
-  *  OPERATION depends on the SCEP transaction and is defined in the
+*  OPERATION depends on the SCEP transaction and is defined in the
-      following sections.
+  following sections.
-  *  HTTP-version is the HTTP version string, which is "HTTP/1.1" for
+*  HTTP-version is the HTTP version string, which is "HTTP/1.1" for
-      [RFC7230].
+  [[RFC7230]].
-  *  SP and CRLF are space and carriage return/linefeed, as defined in
+*  SP and CRLF are space and carriage return/linefeed, as defined in
-      [RFC5234].
+  [[RFC5234]].
-  The CA will typically ignore SCEPPATH, since it's unlikely to be
+The CA will typically ignore SCEPPATH, since it's unlikely to be
-  issuing certificates via a web server.  Clients SHOULD set SCEPPATH
+issuing certificates via a web server.  Clients SHOULD set SCEPPATH
-  to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do
+to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do
-  otherwise by the CA.  The CA SHOULD ignore the SCEPPATH unless its
+otherwise by the CA.  The CA SHOULD ignore the SCEPPATH unless its
-  precise format is critical to the CA's operation.
+precise format is critical to the CA's operation.
-  Early SCEP drafts performed all communications via GET messages,
+Early SCEP drafts performed all communications via GET messages,
-  including non-idempotent ones that should have been sent via POST
+including non-idempotent ones that should have been sent via POST
-  messages; see [HTTP] for details.  This has caused problems because
+messages; see [HTTP] for details.  This has caused problems because
-  of the way that the (supposedly) idempotent GET interacts with caches
+of the way that the (supposedly) idempotent GET interacts with caches
-  and proxies, and because the extremely large GET requests created by
+and proxies, and because the extremely large GET requests created by
-  encoding CMS messages may be truncated in transit.  These issues are
+encoding CMS messages may be truncated in transit.  These issues are
-  typically not visible when testing on a LAN, but crop up during
+typically not visible when testing on a LAN, but crop up during
-  deployment over WANs.  If the remote CA supports POST, the CMS-
+deployment over WANs.  If the remote CA supports POST, the CMS-
-  encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET.
+encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET.
-  This applies to any SCEP message except GetCACert, GetNextCACert, and
+This applies to any SCEP message except GetCACert, GetNextCACert, and
-  GetCACaps and avoids the need for base64 and URL encoding that's
+GetCACaps and avoids the need for base64 and URL encoding that's
-  required for GET messaging.  The client can verify that the CA
+required for GET messaging.  The client can verify that the CA
-  supports SCEP messages via POST by looking for the "SCEPStandard" or
+supports SCEP messages via POST by looking for the "SCEPStandard" or
-  "POSTPKIOperation" capability (see Section 3.5.2).
+"POSTPKIOperation" capability (see Section 3.5.2).
-  If a client or CA uses HTTP GET and encounters HTTP-related problems
+If a client or CA uses HTTP GET and encounters HTTP-related problems
-  such as messages being truncated, seeing errors such as HTTP 414
+such as messages being truncated, seeing errors such as HTTP 414
-  ("Request-URI too long"), or simply having the message not sent/
+("Request-URI too long"), or simply having the message not sent/
-  received at all when standard requests to the server (for example,
+received at all when standard requests to the server (for example,
-  via a web browser) work, then this is a symptom of the problematic
+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
+use of HTTP GET.  The solution to this problem is to update the
-  implementation to use HTTP POST instead.  In addition, when using
+implementation to use HTTP POST instead.  In addition, when using
-  GET, it's recommended to test the implementation from as many
+GET, it's recommended to test the implementation from as many
-  different network locations as possible to determine whether the use
+different network locations as possible to determine whether the use
-  of GET will cause problems with communications.
+of GET will cause problems with communications.
-  When using GET messages to communicate binary data, base64 encoding
+When using GET messages to communicate binary data, base64 encoding
-  as specified in Section 4 of [RFC4648] MUST be used.  The
+as specified in Section 4 of [[RFC4648]] MUST be used.  The
-  base64-encoded data is distinct from "base64url" and may contain URI
+base64-encoded data is distinct from "base64url" and may contain URI
-  reserved characters; thus, it MUST be escaped as specified in
+reserved characters; thus, it MUST be escaped as specified in
-  [RFC3986] in addition to being base64 encoded.  Finally, the encoded
+[[RFC3986]] in addition to being base64 encoded.  Finally, the encoded
-  data is inserted into the MESSAGE portion of the HTTP GET request.
+data is inserted into the MESSAGE portion of the HTTP GET request.
-.2.  Get CA Certificate
+=== Get CA Certificate ===
-  To get the CA certificate(s), the client sends a GetCACert message to
+To get the CA certificate(s), the client sends a GetCACert message to
-  the CA.  The OPERATION MUST be set to "GetCACert".  There is no
+the CA.  The OPERATION MUST be set to "GetCACert".  There is no
-  request data associated with this message.
+request data associated with this message.
-.2.1.  Get CA Certificate Response Message Format
+==== Get CA Certificate Response Message Format ====
-  The response for GetCACert is different between the case where the CA
+The response for GetCACert is different between the case where the CA
-  directly communicates with the client during the enrolment and the
+directly communicates with the client during the enrolment and the
-  case where an intermediate CA exists and the client communicates with
+case where an intermediate CA exists and the client communicates with
-  this CA during the enrolment.
+this CA during the enrolment.
-.2.1.1.  CA Certificate Response Message Format
+===== CA Certificate Response Message Format =====
-  If the CA does not have any intermediate CA certificates, the
+If the CA does not have any intermediate CA certificates, the
-  response consists of a single X.509 CA certificate.  The response
+response consists of a single X.509 CA certificate.  The response
-  will have a Content-Type of "application/x-x509-ca-cert".
+will have a Content-Type of "application/x-x509-ca-cert".
-  "Content-Type: application/x-x509-ca-cert"
+"Content-Type: application/x-x509-ca-cert"
-  <binary X.509>
+<binary X.509>
-.2.1.2.  CA Certificate Chain Response Message Format
+===== CA Certificate Chain Response Message Format =====
-  If the CA has intermediate CA certificates, the response consists of
+If the CA has intermediate CA certificates, the response consists of
-  a degenerate certificates-only CMS SignedData message (Section 3.4)
+a degenerate certificates-only CMS SignedData message (Section 3.4)
-  containing the certificates, with the intermediate CA certificate(s)
+containing the certificates, with the intermediate CA certificate(s)
-  as the leaf certificate(s).  The response will have a Content-Type of
+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
+"application/x-x509-ca-ra-cert".  Note that this designation is used
-  for historical reasons due to its use in older versions of this
+for historical reasons due to its use in older versions of this
-  specification -- no special meaning should be attached to the label.
+specification -- no special meaning should be attached to the label.
-  "Content-Type: application/x-x509-ca-ra-cert"
+"Content-Type: application/x-x509-ca-ra-cert"
-  <binary CMS>
+<binary CMS>
-.3.  Certificate Enrolment/Renewal
+=== Certificate Enrolment/Renewal ===
-  A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a
+A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a
-  certificate enrolment or renewal transaction.  The OPERATION MUST be
+certificate enrolment or renewal transaction.  The OPERATION MUST be
-  set to "PKIOperation".  Note that when used with HTTP POST, the only
+set to "PKIOperation".  Note that when used with HTTP POST, the only
-  OPERATION possible is "PKIOperation", so many CAs don't check this
+OPERATION possible is "PKIOperation", so many CAs don't check this
-  value or even notice its absence.  When implemented using HTTP POST,
+value or even notice its absence.  When implemented using HTTP POST,
-  the message is sent with a Content-Type of "application/x-pki-
+the message is sent with a Content-Type of "application/x-pki-
-  message" and might look as follows:
+message" and might look as follows:
-  POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
+POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
-  Content-Length: <length of data>
+Content-Length: <length of data>
-  Content-Type: application/x-pki-message
+Content-Type: application/x-pki-message
-  <binary CMS data>
+<binary CMS data>
-  When implemented using HTTP GET, this might look as follows:
+When implemented using HTTP GET, this might look as follows:
-  GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \
+GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \
-  message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
+message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
-  IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1
-.3.1.  Certificate Enrolment/Renewal Response Message
+==== Certificate Enrolment/Renewal Response Message ====
-  If the request is granted, a CertRep SUCCESS message
+If the request is granted, a CertRep SUCCESS message
-  (Section 3.3.2.1) is returned.  If the request is rejected, a CertRep
+(Section 3.3.2.1) is returned.  If the request is rejected, a CertRep
-  FAILURE message (Section 3.3.2.2) is returned.  If the CA is
+FAILURE message (Section 3.3.2.2) is returned.  If the CA is
-  configured to manually authenticate the client, a CertRep PENDING
+configured to manually authenticate the client, a CertRep PENDING
-  message (Section 3.3.2.3) MAY be returned.  The CA MAY return a
+message (Section 3.3.2.3) MAY be returned.  The CA MAY return a
-  PENDING for other reasons.
+PENDING for other reasons.
-  The response will have a Content-Type of "application/x-pki-message".
+The response will have a Content-Type of "application/x-pki-message".
-  "Content-Type: application/x-pki-message"
+"Content-Type: application/x-pki-message"
-  <binary CertRep message>
+<binary CertRep message>
-.4.  Poll for Client Initial Certificate
+=== Poll for Client Initial Certificate ===
-  When the client receives a CertRep message with pkiStatus set to
+When the client receives a CertRep message with pkiStatus set to
-  PENDING, it will enter the polling state by periodically sending
+PENDING, it will enter the polling state by periodically sending
-  CertPoll messages to the CA until either the request is granted and
+CertPoll messages to the CA until either the request is granted and
-  the certificate is sent back or the request is rejected or some
+the certificate is sent back or the request is rejected or some
-  preconfigured time limit for polling or maximum number of polls is
+preconfigured time limit for polling or maximum number of polls is
-  exceeded.  The OPERATION MUST be set to "PKIOperation".
+exceeded.  The OPERATION MUST be set to "PKIOperation".
-  CertPoll messages exchanged during the polling period MUST carry the
+CertPoll messages exchanged during the polling period MUST carry the
-  same transactionID attribute as the previous PKCSReq/RenewalReq.  A
+same transactionID attribute as the previous PKCSReq/RenewalReq.  A
-  CA receiving a CertPoll for which it does not have a matching
+CA receiving a CertPoll for which it does not have a matching
-  PKCSReq/RenewalReq MUST reject this request.
+PKCSReq/RenewalReq MUST reject this request.
-  Since at this time the certificate has not been issued, the client
+Since at this time the certificate has not been issued, the client
-  can only use its own subject name (which was contained in the
+can only use its own subject name (which was contained in the
-  original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled
+original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled
-  certificate request (but see the note on identification during
+certificate request (but see the note on identification during
-  polling in Section 3.3.3).  In theory, there can be multiple
+polling in Section 3.3.3).  In theory, there can be multiple
-  outstanding requests from one client (for example, if different keys
+outstanding requests from one client (for example, if different keys
-  and different key usages were used to request multiple certificates),
+and different key usages were used to request multiple certificates),
-  so the transactionID must also be included to disambiguate between
+so the transactionID must also be included to disambiguate between
-  multiple requests.  In practice, however, the client SHOULD NOT have
+multiple requests.  In practice, however, the client SHOULD NOT have
-  multiple requests outstanding at any one time, since this tends to
+multiple requests outstanding at any one time, since this tends to
-  confuse some CAs.
+confuse some CAs.
-.4.1.  Polling Response Message Format
+==== Polling Response Message Format ====
-  The response messages for CertPoll are the same as in Section 4.3.1.
+The response messages for CertPoll are the same as in Section 4.3.1.
-.5.  Certificate Access
+=== Certificate Access ===
-  A client can query an issued certificate from the SCEP CA, as long as
+A client can query an issued certificate from the SCEP CA, as long as
-  the client knows the issuer name and the issuer-assigned certificate
+the client knows the issuer name and the issuer-assigned certificate
-  serial number.
+serial number.
-  This transaction consists of one GetCert (Section 3.3.4) message sent
+This transaction consists of one GetCert (Section 3.3.4) message sent
-  to the CA by a client and one CertRep (Section 3.3.2) message sent
+to the CA by a client and one CertRep (Section 3.3.2) message sent
-  back from the CA.  The OPERATION MUST be set to "PKIOperation".
+back from the CA.  The OPERATION MUST be set to "PKIOperation".
-.5.1.  Certificate Access Response Message Format
+==== Certificate Access Response Message Format ====
-  In this case, the CertRep from the CA is same as in Section 4.3.1,
+In this case, the CertRep from the CA is same as in Section 4.3.1,
-  except that the CA will either grant the request (SUCCESS) or reject
+except that the CA will either grant the request (SUCCESS) or reject
-  it (FAILURE).
+it (FAILURE).
-.6.  CRL Access
+=== CRL Access ===
-  Clients can request a CRL from the SCEP CA, as described in
+Clients can request a CRL from the SCEP CA, as described in
-  Section 2.7.  The OPERATION MUST be set to "PKIOperation".
+Section 2.7.  The OPERATION MUST be set to "PKIOperation".
-.6.1.  CRL Access Response Message Format
+==== CRL Access Response Message Format ====
-  The CRL is sent back to the client in a CertRep (Section 3.3.2)
+The CRL is sent back to the client in a CertRep (Section 3.3.2)
-  message.  The information portion of this message is a degenerate
+message.  The information portion of this message is a degenerate
-  certificates-only SignedData (Section 3.4) that contains only the
+certificates-only SignedData (Section 3.4) that contains only the
-  most recent CRL in the crls field of the SignedData.
+most recent CRL in the crls field of the SignedData.
-.7.  Get Next Certificate Authority Certificate
+=== Get Next Certificate Authority Certificate ===
-  When a CA certificate is about to expire, clients need to retrieve
+When a CA certificate is about to expire, clients need to retrieve
-  the CA's next CA certificate (i.e., the rollover certificate).  This
+the CA's next CA certificate (i.e., the rollover certificate).  This
-  is done via the GetNextCACert message.  The OPERATION MUST be set to
+is done via the GetNextCACert message.  The OPERATION MUST be set to
-  "GetNextCACert".  There is no request data associated with this
+"GetNextCACert".  There is no request data associated with this
-  message.
+message.
-.7.1.  Get Next CA Response Message Format
+==== Get Next CA Response Message Format ====
-  The response consists of a SignedData CMS message, signed by the
+The response consists of a SignedData CMS message, signed by the
-  current CA signing key.  Clients MUST validate the signature on the
+current CA signing key.  Clients MUST validate the signature on the
-  message before trusting any of its contents.  The response will have
+message before trusting any of its contents.  The response will have
-  a Content-Type of "application/x-x509-next-ca-cert".
+a Content-Type of "application/x-x509-next-ca-cert".
-  "Content-Type: application/x-x509-next-ca-cert"
+"Content-Type: application/x-x509-next-ca-cert"
-  <binary CMS>
+<binary CMS>
-  The content of the SignedData message is a degenerate certificates-
+The content of the SignedData message is a degenerate certificates-
-  only SignedData message (Section 3.4) containing the new CA
+only SignedData message (Section 3.4) containing the new CA
-  certificate(s) to be used when the current CA certificate expires.
+certificate(s) to be used when the current CA certificate expires.
-.  SCEP Transaction Examples
+== SCEP Transaction Examples ==
-  The following section gives several examples of client-to-CA
+The following section gives several examples of client-to-CA
-  transactions.  Client actions are indicated in the left column, CA
+transactions.  Client actions are indicated in the left column, CA
-  actions are indicated in the right column, and the transactionID is
+actions are indicated in the right column, and the transactionID is
-  given in parentheses.  For ease of reading, small integer values have
+given in parentheses.  For ease of reading, small integer values have
-  been used; in practice, full transaction IDs would be used.  The
+been used; in practice, full transaction IDs would be used.  The
-  first transaction, for example, would read like this:
+first transaction, for example, would read like this:
-  |  Client Sends PKCSReq message with transactionID 1 to the CA.  The
+|  Client Sends PKCSReq message with transactionID 1 to the CA.  The
-  |  CA signs the certificate and constructs a CertRep Message
+|  CA signs the certificate and constructs a CertRep Message
-  |  containing the signed certificate with a transaction ID 1.  The
+|  containing the signed certificate with a transaction ID 1.  The
-  |  client receives the message and installs the certificate locally.
+|  client receives the message and installs the certificate locally.
-.1.  Successful Transactions
+=== Successful Transactions ===
-  PKCSReq (1)            ----------> CA issues certificate
+PKCSReq (1)            ----------> CA issues certificate
-                          <---------- CertRep (1) SUCCESS
+                        <---------- CertRep (1) SUCCESS
-  Client installs certificate
+Client installs certificate
-        Figure 7: Successful Enrolment Case: Automatic Processing
+      Figure 7: Successful Enrolment Case: Automatic Processing
-  PKCSReq (2)            ----------> Cert request goes into queue
+PKCSReq (2)            ----------> Cert request goes into queue
-                          <---------- CertRep (2) PENDING
+                        <---------- CertRep (2) PENDING
-  CertPoll (2)            ----------> Still pending
+CertPoll (2)            ----------> Still pending
-                          <---------- CertRep (2) PENDING
+                        <---------- CertRep (2) PENDING
-  CertPoll (2)            ----------> CA issues certificate
+CertPoll (2)            ----------> CA issues certificate
-                          <---------- CertRep (2) SUCCESS
+                        <---------- CertRep (2) SUCCESS
-  Client installs certificate
+Client installs certificate
-    Figure 8: Successful Enrolment Case: Manual Authentication Required
+ Figure 8: Successful Enrolment Case: Manual Authentication Required
-  GetNextCACert        ---------->
+GetNextCACert        ---------->
-                        <---------- New CA certificate
+                      <---------- New CA certificate
-  PKCSReq*              ----------> CA issues certificate with
+PKCSReq*              ----------> CA issues certificate with
-                                    new key
+                                  new key
-                        <---------- CertRep SUCCESS
+                      <---------- CertRep SUCCESS
-  Client stores certificate
+Client stores certificate
-  for installation when
+for installation when
-  existing certificate expires.
+existing certificate expires.
-                  Figure 9: CA Certificate Rollover Case
+                Figure 9: CA Certificate Rollover Case
-  * Enveloped for the new CA certificate.  The CA will use the envelope
+* Enveloped for the new CA certificate.  The CA will use the envelope
-  to determine which key to use to issue the client certificate.
+to determine which key to use to issue the client certificate.
-.2.  Transactions with Errors
+=== Transactions with Errors ===
-  In the case of polled transactions that aren't completed
+In the case of polled transactions that aren't completed
-  automatically, there are two potential options for dealing with a
+automatically, there are two potential options for dealing with a
-  transaction that's interrupted due to network or software/hardware
+transaction that's interrupted due to network or software/hardware
-  issues.  The first is for the client to preserve its transaction
+issues.  The first is for the client to preserve its transaction
-  state and resume the CertPoll polling when normal service is
+state and resume the CertPoll polling when normal service is
-  restored.  The second is for the client to begin a new transaction by
+restored.  The second is for the client to begin a new transaction by
-  sending a new PKCSReq/RenewalReq, rather than continuing the previous
+sending a new PKCSReq/RenewalReq, rather than continuing the previous
-  CertPoll.  Both options have their own advantages and disadvantages.
+CertPoll.  Both options have their own advantages and disadvantages.
-  The CertPoll continuation requires that the client maintain its
+The CertPoll continuation requires that the client maintain its
-  transaction state for the time when it resumes polling.  This is
+transaction state for the time when it resumes polling.  This is
-  relatively simple if the problem is a brief network outage, but less
+relatively simple if the problem is a brief network outage, but less
-  simple when the problem is a client crash and restart.  In addition,
+simple when the problem is a client crash and restart.  In addition,
-  the CA may treat a lost network connection as the end of a
+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
+transaction, so that a new connection followed by a CertPoll will be
-  treated as an error.
+treated as an error.
-  The PKCSReq/RenewalReq continuation doesn't require any state to be
+The PKCSReq/RenewalReq continuation doesn't require any state to be
-  maintained, since it's a new transaction.  However, it may cause
+maintained, since it's a new transaction.  However, it may cause
-  problems on the CA side if the certificate was successfully issued
+problems on the CA side if the certificate was successfully issued
-  but the client never received it, since the resumed transaction
+but the client never received it, since the resumed transaction
-  attempt will appear to be a request for a duplicate certificate (see
+attempt will appear to be a request for a duplicate certificate (see
-  Section 7.4 for more on why this is a problem).  In this case, the CA
+Section 7.4 for more on why this is a problem).  In this case, the CA
-  may refuse the transaction or require manual intervention to remove/
+may refuse the transaction or require manual intervention to remove/
-  revoke the previous certificate before the client can request another
+revoke the previous certificate before the client can request another
-  one.
+one.
-  Since the new-transaction resume is more robust in the presence of
+Since the new-transaction resume is more robust in the presence of
-  errors and doesn't require special-case handling by either the client
+errors and doesn't require special-case handling by either the client
-  or CA, clients SHOULD use the new-transaction option in preference to
+or CA, clients SHOULD use the new-transaction option in preference to
-  the resumed-CertPoll option to recover from errors.
+the resumed-CertPoll option to recover from errors.
-  Resync Case 1: Client resyncs via new PKCSReq (recommended):
+Resync Case 1: Client resyncs via new PKCSReq (recommended):
-  PKCSReq (3)          ----------> Cert request goes into queue
+PKCSReq (3)          ----------> Cert request goes into queue
-                        <---------- CertRep (3) PENDING
+                      <---------- CertRep (3) PENDING
-  CertPoll (3)          ----------> Still pending
+CertPoll (3)          ----------> Still pending
-                          X-------- CertRep(3) PENDING
+                        X-------- CertRep(3) PENDING
-  (Network outage)
+(Network outage)
-  (Client reconnects)
+(Client reconnects)
-  PKCSReq (4)          ---------->
+PKCSReq (4)          ---------->
-                        <---------- CertRep (4) PENDING
+                      <---------- CertRep (4) PENDING
-  etc...
+etc...
-                          Figure 10: Resync Case 1
+                      Figure 10: Resync Case 1
-  Resync Case 2: Client resyncs via resumed CertPoll after a network
+Resync Case 2: Client resyncs via resumed CertPoll after a network
-  outage (not recommended; use PKCSReq to resync):
+outage (not recommended; use PKCSReq to resync):
-  PKCSReq (5)          ----------> Cert request goes into queue
+PKCSReq (5)          ----------> Cert request goes into queue
-                        <---------- CertRep (5) PENDING
+                      <---------- CertRep (5) PENDING
-  CertPoll (5)          ----------> Still pending
+CertPoll (5)          ----------> Still pending
-                          X-------- CertRep(5) PENDING
+                        X-------- CertRep(5) PENDING
-  (Network outage)
+(Network outage)
-  (Client reconnects)
+(Client reconnects)
-  CertPoll (5)          ----------> CA issues certificate
+CertPoll (5)          ----------> CA issues certificate
-                        <---------- CertRep (5) SUCCESS
+                      <---------- CertRep (5) SUCCESS
-  Client installs certificate
+Client installs certificate
-                          Figure 11: Resync Case 2
+                      Figure 11: Resync Case 2
-  Resync Case 3: Special-case variation of Case 2 where the CertRep
+Resync Case 3: Special-case variation of Case 2 where the CertRep
-  SUCCESS rather than the CertRep PENDING is lost (recommended):
+SUCCESS rather than the CertRep PENDING is lost (recommended):
-  PKCSReq (6)          ----------> Cert request goes into queue
+PKCSReq (6)          ----------> Cert request goes into queue
-                        <---------- CertRep (6) PENDING
+                      <---------- CertRep (6) PENDING
-  CertPoll (6)          ----------> Still pending
+CertPoll (6)          ----------> Still pending
-                        <---------- CertRep (6) PENDING
+                      <---------- CertRep (6) PENDING
-  CertPoll (6)          ----------> CA issues certificate
+CertPoll (6)          ----------> CA issues certificate
-                          X-------- CertRep(6) SUCCESS
+                        X-------- CertRep(6) SUCCESS
-  (Network outage)
+(Network outage)
-  (Client reconnects)
+(Client reconnects)
-  PKCSReq (7)          ----------> There is already a valid
+PKCSReq (7)          ----------> There is already a valid
-                                    certificate with this
+                                  certificate with this
-                                    Distinguished Name (DN).
+                                  Distinguished Name (DN).
-                        <---------- CertRep (7) FAILURE
+                      <---------- CertRep (7) FAILURE
-                                    Admin revokes certificate
+                                  Admin revokes certificate
-  PKCSReq (8)          ----------> CA issues new certificate
+PKCSReq (8)          ----------> CA issues new certificate
-                        <---------- CertRep (8) SUCCESS
+                      <---------- CertRep (8) SUCCESS
-  Client installs certificate
+Client installs certificate
-                          Figure 12: Resync Case 3
+                      Figure 12: Resync Case 3
-  Resync Case 4: Special-case variation of Case 1 where the CertRep
+Resync Case 4: Special-case variation of Case 1 where the CertRep
-  SUCCESS rather than the CertRep PENDING is lost (not recommended; use
+SUCCESS rather than the CertRep PENDING is lost (not recommended; use
-  PKCSReq to resync):
+PKCSReq to resync):
-  PKCSReq (9)          ----------> Cert request goes into queue
+PKCSReq (9)          ----------> Cert request goes into queue
-                        <---------- CertRep (9) PENDING
+                      <---------- CertRep (9) PENDING
-  CertPoll (9)          ----------> Still pending
+CertPoll (9)          ----------> Still pending
-                        <---------- CertRep (9) PENDING
+                      <---------- CertRep (9) PENDING
-  CertPoll (9)          ----------> CA issues certificate
+CertPoll (9)          ----------> CA issues certificate
-                          X-------- CertRep(9) SIGNED CERT
+                        X-------- CertRep(9) SIGNED CERT
-  (Network outage)
+(Network outage)
-  (Client reconnects)
+(Client reconnects)
-  CertPoll (9)          ----------> Certificate already issued
+CertPoll (9)          ----------> Certificate already issued
-                        <---------- CertRep (9) SUCCESS
+                      <---------- CertRep (9) SUCCESS
-  Client installs certificate
+Client installs certificate
-                          Figure 13: Resync Case 4
+                      Figure 13: Resync Case 4
-  As these examples indicate, resumption from an error via a resumed
+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
+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
+client and/or the CA.  A PKCSReq/RenewalReq resume is the easiest to
-  implement, since it's stateless and is identical for both polled and
+implement, since it's stateless and is identical for both polled and
-  nonpolled transactions, whereas a CertPoll resume treats the two
+nonpolled transactions, whereas a CertPoll resume treats the two
-  differently.  (A nonpolled transaction is resumed with a PKCSReq/
+differently.  (A nonpolled transaction is resumed with a PKCSReq/
-  RenewalReq; a polled transaction is resumed with a CertPoll.)  For
+RenewalReq; a polled transaction is resumed with a CertPoll.)  For
-  this reason, error recovery SHOULD be handled via a new PKCSReq
+this reason, error recovery SHOULD be handled via a new PKCSReq
-  rather than a resumed CertPoll.
+rather than a resumed CertPoll.
-.  IANA Considerations
+== IANA Considerations ==
-  An object identifier for an arc to assign SCEP Attribute Identifiers
+An object identifier for an arc to assign SCEP Attribute Identifiers
-  has been assigned in the "SMI Security for PKIX" registry
+has been assigned in the "SMI Security for PKIX" registry
-  (1.3.6.1.5.5.7).  This object identifer, Simple Certificate
+(1.3.6.1.5.5.7).  This object identifer, Simple Certificate
-  Enrollment Protocol Attributes, is denoted as id-scep:
+Enrollment Protocol Attributes, is denoted as id-scep:
-  id-scep OBJECT IDENTIFIER ::= { id-pkix 24 }
+id-scep OBJECT IDENTIFIER ::= { id-pkix 24 }
-  IANA created the "SMI Security for SCEP Attribute Identifiers"
+IANA created the "SMI Security for SCEP Attribute Identifiers"
-  registry (1.3.6.1.5.5.7.24) with the following entries with
+registry (1.3.6.1.5.5.7.24) with the following entries with
-  references to this document:
+references to this document:
-  id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }
+id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }
-  Entries in the registry are assigned according to the "Specification
+Entries in the registry are assigned according to the "Specification
-  Required" policy defined in [RFC8126].
+Required" policy defined in [[RFC8126]].
-  Section 3.2.1.2 describes an "SCEP Message Type" registry, and
+Section 3.2.1.2 describes an "SCEP Message Type" registry, and
-  Section 3.5 describes an "SCEP CA Capabilities" registry; these
+Section 3.5 describes an "SCEP CA Capabilities" registry; these
-  registries are maintained by IANA and define a number of such code-
+registries are maintained by IANA and define a number of such code-
-  point identifiers.  Entries in the registry are assigned according to
+point identifiers.  Entries in the registry are assigned according to
-  the "Specification Required" policy defined in [RFC8126].
+the "Specification Required" policy defined in [[RFC8126]].
-  The "SCEP Message Types" registry has "Value", "Name", "Description",
+The "SCEP Message Types" registry has "Value", "Name", "Description",
-  and "Reference" columns.  The "Value" entry is a small positive
+and "Reference" columns.  The "Value" entry is a small positive
-  integer; value "0" is reserved.
+integer; value "0" is reserved.
-  The "SCEP CA Capabilities" registry has "Keyword", "Description", and
+The "SCEP CA Capabilities" registry has "Keyword", "Description", and
-  "Reference" columns.  Although implementations SHOULD use the "SCEP
+"Reference" columns.  Although implementations SHOULD use the "SCEP
-  CA Capabilities" registry, SCEP is often employed in situations where
+CA Capabilities" registry, SCEP is often employed in situations where
-  this isn't possible.  In this case, private-use CA capabilities may
+this isn't possible.  In this case, private-use CA capabilities may
-  be specified using a unique prefix such as an organisation identifier
+be specified using a unique prefix such as an organisation identifier
-  or domain name under the control of the entity that defines the
+or domain name under the control of the entity that defines the
-  capability.  For example, the prefix would be "Example.com-", and the
+capability.  For example, the prefix would be "Example.com-", and the
-  complete capability would be "Example.com-CapabilityName".
+complete capability would be "Example.com-CapabilityName".
-  IANA has registered four media types as defined in this document:
+IANA has registered four media types as defined in this document:
-  *  application/x-x509-ca-cert
+*  application/x-x509-ca-cert
-  *  application/x-x509-ca-ra-cert
+*  application/x-x509-ca-ra-cert
-  *  application/x-x509-next-ca-cert
+*  application/x-x509-next-ca-cert
-  *  application/x-pki-message
+*  application/x-pki-message
-  Note that these are grandfathered media types registered as per
+Note that these are grandfathered media types registered as per
-  Appendix A of [RFC6838].  Templates for registrations are specified
+Appendix A of [[RFC6838]].  Templates for registrations are specified
-  below.
+below.
-.1.  Registration of the application/x-x509-ca-cert Media Type
+=== Registration of the application/x-x509-ca-cert Media Type ===
-  Type name:  application
+Type name:  application
-  Subtype name:  x-x509-ca-cert
+Subtype name:  x-x509-ca-cert
-  Required parameters:  none
+Required parameters:  none
-  Optional parameters:  none
+Optional parameters:  none
-  Encoding considerations:  binary
+Encoding considerations:  binary
-  Security considerations:  This media type contains a certificate; see
+Security considerations:  This media type contains a certificate; see
-      the Security Considerations section of [RFC5280].  There is no
+  the Security Considerations section of [[RFC5280]].  There is no
-      executable content.
+  executable content.
-  Interoperability considerations:  This is a grandfathered
+Interoperability considerations:  This is a grandfathered
-      registration of an alias to application/pkix-cert (basically a
+  registration of an alias to application/pkix-cert (basically a
-      single DER-encoded Certification Authority certificate), which is
+  single DER-encoded Certification Authority certificate), which is
-      only used in SCEP.
+  only used in SCEP.
-  Published specification:  RFC 8894
+Published specification:  [[RFC8894|RFC 8894]]
-  Applications that use this media type:  SCEP uses this media type
+Applications that use this media type:  SCEP uses this media type
-      when returning a CA certificate.
+  when returning a CA certificate.
-  Fragment identifier considerations:  N/A
+Fragment identifier considerations:  N/A
-  Additional information:
+Additional information:
-      Deprecated alias names for this type:  N/A
+  Deprecated alias names for this type:  N/A
-      Magic number(s):  none
+  Magic number(s):  none
-      File extension(s):  N/A
+  File extension(s):  N/A
-      Macintosh file type code(s):  N/A
+  Macintosh file type code(s):  N/A
-  Person and email address to contact for further information:  See the
+Person and email address to contact for further information:  See the
-      Authors' Addresses section of RFC 8894.
+  Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Intended usage:  LIMITED USE
+Intended usage:  LIMITED USE
-  Restrictions on usage:  SCEP protocol
+Restrictions on usage:  SCEP protocol
-  Author:  See the Authors' Addresses section of RFC 8894
+Author:  See the Authors' Addresses section of [[RFC8894|RFC 8894]]
-  Change controller:  IETF
+Change controller:  IETF
-  Provisional registration?  No
+Provisional registration?  No
-.2.  Registration of the application/x-x509-ca-ra-cert Media Type
+=== Registration of the application/x-x509-ca-ra-cert Media Type ===
-  Type name:  application
+Type name:  application
-  Subtype name:  x-x509-ca-ra-cert
+Subtype name:  x-x509-ca-ra-cert
-  Required parameters:  none
+Required parameters:  none
-  Optional parameters:  none
+Optional parameters:  none
-  Encoding considerations:  binary
+Encoding considerations:  binary
-  Security considerations:  This media type consists of a degenerate
+Security considerations:  This media type consists of a degenerate
-      certificates-only CMS SignedData message (Section 3.4) containing
+  certificates-only CMS SignedData message (Section 3.4) containing
-      the certificates, with the intermediate CA certificate(s) as the
+  the certificates, with the intermediate CA certificate(s) as the
-      leaf certificate(s).  There is no executable content.
+  leaf certificate(s).  There is no executable content.
-  Interoperability considerations:  This is a grandfathered
+Interoperability considerations:  This is a grandfathered
-      registration that is only used in SCEP.
+  registration that is only used in SCEP.
-  Published specification:  RFC 8894
+Published specification:  [[RFC8894|RFC 8894]]
-  Applications that use this media type:  SCEP uses this media type
+Applications that use this media type:  SCEP uses this media type
-      when returning CA Certificate Chain Response.
+  when returning CA Certificate Chain Response.
-  Fragment identifier considerations:  N/A
+Fragment identifier considerations:  N/A
-  Additional information:
+Additional information:
-      Deprecated alias names for this type:  N/A
+  Deprecated alias names for this type:  N/A
-      Magic number(s):  none
+  Magic number(s):  none
-      File extension(s):  N/A
+  File extension(s):  N/A
-      Macintosh file type code(s):  N/A
+  Macintosh file type code(s):  N/A
-  Person and email address to contact for further information:  See the
+Person and email address to contact for further information:  See the
-      Authors' Addresses section of RFC 8894.
+  Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Intended usage:  LIMITED USE
+Intended usage:  LIMITED USE
-  Restrictions on usage:  SCEP protocol
+Restrictions on usage:  SCEP protocol
-  Author:  See the Authors' Addresses section of RFC 8894.
+Author:  See the Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Change controller:  IETF
+Change controller:  IETF
-  Provisional registration?  no
+Provisional registration?  no
-.3.  Registration of the application/x-x509-next-ca-cert Media Type
+=== Registration of the application/x-x509-next-ca-cert Media Type ===
-  Type name:  application
+Type name:  application
-  Subtype name:  x-x509-next-ca-cert
+Subtype name:  x-x509-next-ca-cert
-  Required parameters:  none
+Required parameters:  none
-  Optional parameters:  none
+Optional parameters:  none
-  Encoding considerations:  binary
+Encoding considerations:  binary
-  Security considerations:  This media type consists of a SignedData
+Security considerations:  This media type consists of a SignedData
-      CMS message, signed by the current CA signing key.  There is no
+  CMS message, signed by the current CA signing key.  There is no
-      executable content.
+  executable content.
-  Interoperability considerations:  This is a grandfathered
+Interoperability considerations:  This is a grandfathered
-      registration that is only used in SCEP.
+  registration that is only used in SCEP.
-  Published specification:  RFC 8894
+Published specification:  [[RFC8894|RFC 8894]]
-  Applications that use this media type:  SCEP uses this media type
+Applications that use this media type:  SCEP uses this media type
-      when returning a Get Next CA response.
+  when returning a Get Next CA response.
-  Fragment identifier considerations:  N/A
+Fragment identifier considerations:  N/A
-  Additional information:
+Additional information:
-      Deprecated alias names for this type:  N/A
+  Deprecated alias names for this type:  N/A
-      Magic number(s):  none
+  Magic number(s):  none
-      File extension(s):  N/A
+  File extension(s):  N/A
-      Macintosh file type code(s):  N/A
+  Macintosh file type code(s):  N/A
-  Person and email address to contact for further information:  See the
+Person and email address to contact for further information:  See the
-      Authors' Addresses section of RFC 8894.
+  Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Intended usage:  LIMITED USE
+Intended usage:  LIMITED USE
-  Restrictions on usage:  SCEP protocol
+Restrictions on usage:  SCEP protocol
-  Author:  See the Authors' Addresses section of RFC 8894.
+Author:  See the Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Change controller:  IETF
+Change controller:  IETF
-  Provisional registration?  no
+Provisional registration?  no
-.4.  Registration of the application/x-pki-message Media Type
+=== Registration of the application/x-pki-message Media Type ===
-  Type name:  application
+Type name:  application
-  Subtype name:  x-pki-message
+Subtype name:  x-pki-message
-  Required parameters:  none
+Required parameters:  none
-  Optional parameters:  none
+Optional parameters:  none
-  Encoding considerations:  binary
+Encoding considerations:  binary
-  Security considerations:  This media type consists of a degenerate
+Security considerations:  This media type consists of a degenerate
-      certificates-only CMS SignedData message.  There is no executable
+  certificates-only CMS SignedData message.  There is no executable
-      content.
+  content.
-  Interoperability considerations:  This is a grandfathered
+Interoperability considerations:  This is a grandfathered
-      registration that is only used in SCEP.
+  registration that is only used in SCEP.
-  Published specification:  RFC 8894
+Published specification:  [[RFC8894|RFC 8894]]
-  Applications that use this media type:  SCEP uses this media type
+Applications that use this media type:  SCEP uses this media type
-      when returning a Certificate Enrolment/Renewal Response.
+  when returning a Certificate Enrolment/Renewal Response.
-  Fragment identifier considerations:  N/A
+Fragment identifier considerations:  N/A
-  Additional information:
+Additional information:
-      Deprecated alias names for this type:  N/A
+  Deprecated alias names for this type:  N/A
-      Magic number(s):  none
+  Magic number(s):  none
-      File extension(s):  N/A
+  File extension(s):  N/A
-      Macintosh file type code(s):  N/A
+  Macintosh file type code(s):  N/A
-  Person and email address to contact for further information:  See the
+Person and email address to contact for further information:  See the
-      Authors' Addresses section of RFC 8894.
+  Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Intended usage:  LIMITED USE
+Intended usage:  LIMITED USE
-  Restrictions on usage:  SCEP protocol
+Restrictions on usage:  SCEP protocol
-  Author:  See the Authors' Addresses section of RFC 8894.
+Author:  See the Authors' Addresses section of [[RFC8894|RFC 8894]].
-  Change controller:  IETF
+Change controller:  IETF
-  Provisional registration?  no
+Provisional registration?  no
-.  Security Considerations
+== Security Considerations ==
-  The security goal of SCEP is that no adversary can subvert the public
+The security goal of SCEP is that no adversary can subvert the public
-  key/identity binding from that intended.  An adversary is any entity
+key/identity binding from that intended.  An adversary is any entity
-  other than the client and the CA participating in the protocol.
+other than the client and the CA participating in the protocol.
-  This goal is met through the use of CMS and PKCS #10 encryption and
+This goal is met through the use of CMS and PKCS #10 encryption and
-  digital signatures using authenticated public keys.  The CA's public
+digital signatures using authenticated public keys.  The CA's public
-  key is authenticated via out-of-band means such as the checking of
+key is authenticated via out-of-band means such as the checking of
-  the CA fingerprint, and the SCEP client's public key is authenticated
+the CA fingerprint, and the SCEP client's public key is authenticated
-  through manual or preshared secret authentication.
+through manual or preshared secret authentication.
-.1.  General Security
+=== General Security ===
-  Common key-management considerations such as keeping private keys
+Common key-management considerations such as keeping private keys
-  truly private and using adequate lengths for symmetric and asymmetric
+truly private and using adequate lengths for symmetric and asymmetric
-  keys must be followed in order to maintain the security of this
+keys must be followed in order to maintain the security of this
-  protocol.  This is especially true for CA keys which, when
+protocol.  This is especially true for CA keys which, when
-  compromised, compromise the security of all relying parties.
+compromised, compromise the security of all relying parties.
-.2.  Use of the CA Private Key
+=== Use of the CA Private Key ===
-  A CA private key is generally meant for, and usually flagged as,
+A CA private key is generally meant for, and usually flagged as,
-  being usable for certificate (and CRL) signing exclusively rather
+being usable for certificate (and CRL) signing exclusively rather
-  than data signing or encryption.  The SCEP protocol, however, uses
+than data signing or encryption.  The SCEP protocol, however, uses
-  the CA private key to both sign and optionally encrypt CMS transport
+the CA private key to both sign and optionally encrypt CMS transport
-  messages.  This is generally considered undesirable, as it widens the
+messages.  This is generally considered undesirable, as it widens the
-  possibility of an implementation weakness and provides an additional
+possibility of an implementation weakness and provides an additional
-  location where the private key must be used (and hence is slightly
+location where the private key must be used (and hence is slightly
-  more vulnerable to exposure) and where a side-channel attack might be
+more vulnerable to exposure) and where a side-channel attack might be
-  applied.
+applied.
-.3.  ChallengePassword Shared Secret Value
+=== ChallengePassword Shared Secret Value ===
-  The security measures that should be applied to the challengePassword
+The security measures that should be applied to the challengePassword
-  shared secret depend on the manner in which SCEP is employed.  In the
+shared secret depend on the manner in which SCEP is employed.  In the
-  simplest case, with SCEP used to provision devices with certificates
+simplest case, with SCEP used to provision devices with certificates
-  in the manufacturing facility, the physical security of the facility
+in the manufacturing facility, the physical security of the facility
-  may be enough to protect the certificate issue process with no
+may be enough to protect the certificate issue process with no
-  additional measures explicitly required.  In general, though, the
+additional measures explicitly required.  In general, though, the
-  security of the issue process depends on the security employed around
+security of the issue process depends on the security employed around
-  the use of the challengePassword shared secret.  While it's not
+the use of the challengePassword shared secret.  While it's not
-  possible to enumerate every situation in which SCEP may be utilised,
+possible to enumerate every situation in which SCEP may be utilised,
-  the following security measures should be considered.
+the following security measures should be considered.
-  *  The challengePassword, despite its name, shouldn't be a
+*  The challengePassword, despite its name, shouldn't be a
-      conventional password but a high-entropy shared-secret
+  conventional password but a high-entropy shared-secret
-      authentication string.  Using the base64 encoding of a keying
+  authentication string.  Using the base64 encoding of a keying
-      value generated or exchanged as part of standard device
+  value generated or exchanged as part of standard device
-      authentication protocols like the Extensible Authentication
+  authentication protocols like the Extensible Authentication
-      Protocol (EAP) or DNP3 Secure Authentication (DNP3-SA) makes for a
+  Protocol (EAP) or DNP3 Secure Authentication (DNP3-SA) makes for a
-      good challengePassword.  The use of high-entropy shared secrets is
+  good challengePassword.  The use of high-entropy shared secrets is
-      particularly important when the PasswordRecipientInfo option is
+  particularly important when the PasswordRecipientInfo option is
-      used to encrypt SCEP messages; see Section 3.1.
+  used to encrypt SCEP messages; see Section 3.1.
-  *  If feasible, the challengePassword should be a one-time value used
+*  If feasible, the challengePassword should be a one-time value used
-      to authenticate the issue of a single certificate (subsequent
+  to authenticate the issue of a single certificate (subsequent
-      certificate requests will be authenticated by being signed with
+  certificate requests will be authenticated by being signed with
-      the initial certificate).  If the challengePassword is single use,
+  the initial certificate).  If the challengePassword is single use,
-      then the arrival of subsequent requests using the same
+  then the arrival of subsequent requests using the same
-      challengePassword can then be used to indicate a security breach.
+  challengePassword can then be used to indicate a security breach.
-  *  The lifetime of a challengePassword can be limited, so that it can
+*  The lifetime of a challengePassword can be limited, so that it can
-      be used during initial device provisioning but will have expired
+  be used during initial device provisioning but will have expired
-      at a later date if an attacker manages to compromise the
+  at a later date if an attacker manages to compromise the
-      challengePassword value -- for example, by compromising the device
+  challengePassword value -- for example, by compromising the device
-      that it's stored in.
+  that it's stored in.
-  *  The CA should take appropriate measures to protect the
+*  The CA should take appropriate measures to protect the
-      challengePassword.  Examples of possible measures include:
+  challengePassword.  Examples of possible measures include:
-      physical security measures; storing it as a salted iterated hash
+  physical security measures; storing it as a salted iterated hash
-      or equivalent memory-hard function; storing it as a keyed MAC
+  or equivalent memory-hard function; storing it as a keyed MAC
-      value if it's not being used for encryption; and storing it in
+  value if it's not being used for encryption; and storing it in
-      encrypted form if it is being used for encryption.
+  encrypted form if it is being used for encryption.
-.4.  Lack of Certificate Issue Confirmation
+=== Lack of Certificate Issue Confirmation ===
-  SCEP provides no confirmation that the issued certificate was
+SCEP provides no confirmation that the issued certificate was
-  successfully received and processed by the client.  This means that
+successfully received and processed by the client.  This means that
-  if the CertRep message is lost or can't be processed by the client,
+if the CertRep message is lost or can't be processed by the client,
-  then the CA will consider the certificate successfully issued while
+then the CA will consider the certificate successfully issued while
-  the client won't.  If this situation is of concern, then the correct
+the client won't.  If this situation is of concern, then the correct
-  issuance of the certificate will need to be verified by out-of-band
+issuance of the certificate will need to be verified by out-of-band
-  means, for example, through the client sending a message signed by
+means, for example, through the client sending a message signed by
-  the newly issued certificate to the CA.  This also provides the proof
+the newly issued certificate to the CA.  This also provides the proof
-  of possession that's not present in the case of a renewal operation;
+of possession that's not present in the case of a renewal operation;
-  see Section 7.6.
+see Section 7.6.
-.5.  GetCACaps Issues
+=== GetCACaps Issues ===
-  The GetCACaps response is not authenticated by the CA.  This allows
+The GetCACaps response is not authenticated by the CA.  This allows
-  an attacker to perform downgrade attacks on the cryptographic
+an attacker to perform downgrade attacks on the cryptographic
-  capabilities of the client/CA exchange.  In particular, if the server
+capabilities of the client/CA exchange.  In particular, if the server
-  were to support MD5 and single DES, then an in-path attacker could
+were to support MD5 and single DES, then an in-path attacker could
-  trivially roll back the encryption to use these insecure algorithms.
+trivially roll back the encryption to use these insecure algorithms.
-  By taking advantage of the presence of large amounts of static known
+By taking advantage of the presence of large amounts of static known
-  plaintext in the SCEP messages, as of 2017, a DES rainbow table
+plaintext in the SCEP messages, as of 2017, a DES rainbow table
-  attack can recover most encryption keys in under a minute, and MD5
+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
+chosen-prefix collisions can be calculated for a few tens of cents of
-  computing time using tools like HashClash.  It is for this reason
+computing time using tools like HashClash.  It is for this reason
-  that this specification makes single DES and MD5 a MUST NOT feature.
+that this specification makes single DES and MD5 a MUST NOT feature.
-  Note that all known servers support at least triple DES and SHA-1
+Note that all known servers support at least triple DES and SHA-1
-  (regardless of whether "DES3" and "SHA-1" are indicated in
+(regardless of whether "DES3" and "SHA-1" are indicated in
-  GetCACaps), so there should never be a reason to fall all the way
+GetCACaps), so there should never be a reason to fall all the way
-  back to single DES and MD5.
+back to single DES and MD5.
-  One simple countermeasure to a GetCACaps downgrade attack is for
+One simple countermeasure to a GetCACaps downgrade attack is for
-  clients that are operating in an environment where on-path attacks
+clients that are operating in an environment where on-path attacks
-  are possible and that expect the "SCEPStandard" capability to be
+are possible and that expect the "SCEPStandard" capability to be
-  indicated by the CA but don't see it in the GetCACaps response to
+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
+treat its absence as a security issue, and either discontinue the
-  exchange or continue as if "SCEPStandard" had been returned.  This
+exchange or continue as if "SCEPStandard" had been returned.  This
-  requires a certain trade-off between compatibility with old servers
+requires a certain trade-off between compatibility with old servers
-  and security against active attacks.
+and security against active attacks.
-.6.  Lack of PoP in Renewal Requests
+=== Lack of PoP in Renewal Requests ===
-  Renewal operations (but not standard certificate-issue operations)
+Renewal operations (but not standard certificate-issue operations)
-  are processed via a previously issued certificate and its associated
+are processed via a previously issued certificate and its associated
-  private key, not the key in the PKCS #10 request.  This means that a
+private key, not the key in the PKCS #10 request.  This means that a
-  client no longer demonstrates proof of possession (PoP) of the
+client no longer demonstrates proof of possession (PoP) of the
-  private key corresponding to the public key in the PKCS #10 request.
+private key corresponding to the public key in the PKCS #10 request.
-  It is therefore possible for a client to recertify an existing key
+It is therefore possible for a client to recertify an existing key
-  used by a third party, so that two or more certificates exist for the
+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
+same key.  By switching out the certificate in a signature, an
-  attacker can appear to have a piece of data signed by their
+attacker can appear to have a piece of data signed by their
-  certificate rather than the original signer's certificate.  This, and
+certificate rather than the original signer's certificate.  This, and
-  other, attacks are described in S/MIME ESS [RFC2634].
+other, attacks are described in S/MIME ESS [[RFC2634]].
-  Avoiding these types of attacks requires situation-specific measures.
+Avoiding these types of attacks requires situation-specific measures.
-  For example, CMS/SMIME implementations may use the ESSCertID
+For example, CMS/SMIME implementations may use the ESSCertID
-  attribute from S/MIME ESS [RFC2634] or its successor, S/MIME ESSv2
+attribute from S/MIME ESS [[RFC2634]] or its successor, S/MIME ESSv2
-  [RFC5035], to unambiguously identify the signing certificate.
+[[RFC5035]], to unambiguously identify the signing certificate.
-  However, since other mechanisms and protocols that the certificates
+However, since other mechanisms and protocols that the certificates
-  will be used with typically don't defend against this problem, it's
+will be used with typically don't defend against this problem, it's
-  unclear whether this is an actual issue with SCEP.
+unclear whether this is an actual issue with SCEP.
-.7.  Traffic Monitoring
+=== Traffic Monitoring ===
-  SCEP messages are signed with certificates that may contain
+SCEP messages are signed with certificates that may contain
-  identifying information.  If these are sent over the public Internet
+identifying information.  If these are sent over the public Internet
-  and real identity information (rather than placeholder values or
+and real identity information (rather than placeholder values or
-  arbitrary device IDs) is included in the signing certificate data, an
+arbitrary device IDs) is included in the signing certificate data, an
-  attacker may be able to monitor the identities of the entities
+attacker may be able to monitor the identities of the entities
-  submitting the certificate requests.  If this is an issue, then
+submitting the certificate requests.  If this is an issue, then
-  [RFC7258] should be consulted for guidance.
+[[RFC7258]] should be consulted for guidance.
-.8.  Unnecessary Cryptography
+=== Unnecessary Cryptography ===
-  Some of the SCEP exchanges use unnecessary signing and encryption
+Some of the SCEP exchanges use unnecessary signing and encryption
-  operations.  In particular, the GetCert and GetCRL exchanges are
+operations.  In particular, the GetCert and GetCRL exchanges are
-  encrypted and signed in both directions.  The information requested
+encrypted and signed in both directions.  The information requested
-  is public, and thus encrypting the requests is of questionable value.
+is public, and thus encrypting the requests is of questionable value.
-  In addition, CRLs and certificates sent in responses are already
+In addition, CRLs and certificates sent in responses are already
-  signed by the CA and can be verified by the recipient without
+signed by the CA and can be verified by the recipient without
-  requiring additional signing and encryption.  More lightweight means
+requiring additional signing and encryption.  More lightweight means
-  of retrieving certificates and CRLs such as HTTP certificate-store
+of retrieving certificates and CRLs such as HTTP certificate-store
-  access [RFC4387] and LDAP are recommended for this reason.
+access [[RFC4387]] and LDAP are recommended for this reason.
-.9.  Use of SHA-1
+=== Use of SHA-1 ===
-  The majority of the large number of devices that use SCEP today
+The majority of the large number of devices that use SCEP today
-  default to SHA-1, with many supporting only that hash algorithm with
+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
+no ability to upgrade to a newer one.  SHA-1 is no longer regarded as
-  secure in all situations, but as used in SCEP, it's still safe.
+secure in all situations, but as used in SCEP, it's still safe.
-  There are three reasons for this.  The first is that attacking SCEP
+There are three reasons for this.  The first is that attacking SCEP
-  would require creating a fully general SHA-1 collision in close to
+would require creating a fully general SHA-1 collision in close to
-  real time alongside breaking AES (more specifically, it would require
+real time alongside breaking AES (more specifically, it would require
-  creating a fully general SHA-1 collision for the PKCS #10 request,
+creating a fully general SHA-1 collision for the PKCS #10 request,
-  breaking the AES encryption around the PKCS #10 request, and then
+breaking the AES encryption around the PKCS #10 request, and then
-  creating a second SHA-1 collision for the signature on the encrypted
+creating a second SHA-1 collision for the signature on the encrypted
-  data), which won't be feasible for a long time.
+data), which won't be feasible for a long time.
-  The second reason is that the signature over the message -- in other
+The second reason is that the signature over the message -- in other
-  words, the SHA-1 hash that isn't protected by encryption -- doesn't
+words, the SHA-1 hash that isn't protected by encryption -- doesn't
-  serve any critical cryptographic purpose: The PKCS #10 data itself is
+serve any critical cryptographic purpose: The PKCS #10 data itself is
-  authenticated through its own signature, protected by encryption, and
+authenticated through its own signature, protected by encryption, and
-  the overall request is authorised by the (encrypted) shared secret.
+the overall request is authorised by the (encrypted) shared secret.
-  The sole exception to this will be the small number of
+The sole exception to this will be the small number of
-  implementations that support the Renewal operation, which may be
+implementations that support the Renewal operation, which may be
-  authorised purely through a signature, but presumably any
+authorised purely through a signature, but presumably any
-  implementation recent enough to support Renewal also supports SHA-2.
+implementation recent enough to support Renewal also supports SHA-2.
-  Any legacy implementation that supports the historic core SCEP
+Any legacy implementation that supports the historic core SCEP
-  protocol would not be affected.
+protocol would not be affected.
-  The third reason is that SCEP uses the same key for encryption and
+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
+signing, so that even if an attacker were able to capture an outgoing
-  renewal request that didn't include a shared secret (in other words,
+renewal request that didn't include a shared secret (in other words,
-  one that was only authorised through a signature), break the AES
+one that was only authorised through a signature), break the AES
-  encryption, forge the SHA-1 hash in real time, and forward the forged
+encryption, forge the SHA-1 hash in real time, and forward the forged
-  request to the CA, they couldn't decrypt the returned certificate,
+request to the CA, they couldn't decrypt the returned certificate,
-  which is protected with the same key that was used to generate the
+which is protected with the same key that was used to generate the
-  signature.  While Section 7.8 points out that SCEP uses unnecessary
+signature.  While Section 7.8 points out that SCEP uses unnecessary
-  cryptography in places, the additional level of security provided by
+cryptography in places, the additional level of security provided by
-  the extra crypto makes it immune to any issues with SHA-1.
+the extra crypto makes it immune to any issues with SHA-1.
-  This doesn't mean that SCEP implementations should continue to use
+This doesn't mean that SCEP implementations should continue to use
-  SHA-1 in perpetuity, merely that there's no need for a panicked
+SHA-1 in perpetuity, merely that there's no need for a panicked
-  switch to SHA-2.
+switch to SHA-2.
 .10.  Use of HTTP
-  SCEP is an encrypted, authenticated certificate enrollment protocol
+SCEP is an encrypted, authenticated certificate enrollment protocol
-  that uses HTTP as a simple transport mechanism.  Since SCEP messages
+that uses HTTP as a simple transport mechanism.  Since SCEP messages
-  are already cryptographically secured, it does not require transport
+are already cryptographically secured, it does not require transport
-  layer security.  Where HTTPS is elected, a performance hit may result
+layer security.  Where HTTPS is elected, a performance hit may result
-  from the TLS overhead, operational problems may result due to the
+from the TLS overhead, operational problems may result due to the
-  more complex configuration, and potential security vulnerability may
+more complex configuration, and potential security vulnerability may
-  result due to the addition of an entire TLS protocol stack alongside
+result due to the addition of an entire TLS protocol stack alongside
-  the basic SCEP protocol.
+the basic SCEP protocol.
-  In particular, experience has shown that the issue of configuring
+In particular, experience has shown that the issue of configuring
-  certificates, CAs, and trust for both TLS and SCEP often leads to
+certificates, CAs, and trust for both TLS and SCEP often leads to
-  interoperability problems because different certificates and trust
+interoperability problems because different certificates and trust
-  models are used in each.  Use of HTTPS to authenticate the server
+models are used in each.  Use of HTTPS to authenticate the server
-  does not enable omission of the ChallengePassword or similar
+does not enable omission of the ChallengePassword or similar
-  authenticator in the SCEP message on the assumption that using HTTPS
+authenticator in the SCEP message on the assumption that using HTTPS
-  instead of HTTP will somehow make this insecure usage secure again.
+instead of HTTP will somehow make this insecure usage secure again.
-  HTTPS is not soy sauce for security and is unnecessary for SCEP,
+HTTPS is not soy sauce for security and is unnecessary for SCEP,
-  which uses cryptographically secured messages and does not require
+which uses cryptographically secured messages and does not require
-  transport layer security.
+transport layer security.
-.  References
+== References ==
-.1.  Normative References
+=== Normative References ===
-  [AES]      Technology, U. N. I. O. S. A., "The Advanced Encryption
+[AES]      Technology, U. N. I. O. S. A., "The Advanced Encryption
-              Standard (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197,
+          Standard (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197,
-              November 2001, <https://doi.org/10.6028/NIST.FIPS.197>.
+          November 2001, <https://doi.org/10.6028/NIST.FIPS.197>.
-  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+[[RFC2119]]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
+          Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]],
-              DOI 10.17487/RFC2119, March 1997,
+          DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/info/rfc2119>.
+          <https://www.rfc-editor.org/info/rfc2119>.
-  [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+[[RFC2985]]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
-              Classes and Attribute Types Version 2.0", RFC 2985,
+          Classes and Attribute Types Version 2.0", [[RFC2985|RFC 2985]],
-              DOI 10.17487/RFC2985, November 2000,
+          DOI 10.17487/RFC2985, November 2000,
-              <https://www.rfc-editor.org/info/rfc2985>.
+          <https://www.rfc-editor.org/info/rfc2985>.
-  [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
+[[RFC2986]]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
-              Request Syntax Specification Version 1.7", RFC 2986,
+          Request Syntax Specification Version 1.7", [[RFC2986|RFC 2986]],
-              DOI 10.17487/RFC2986, November 2000,
+          DOI 10.17487/RFC2986, November 2000,
-              <https://www.rfc-editor.org/info/rfc2986>.
+          <https://www.rfc-editor.org/info/rfc2986>.
-  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+[[RFC3986]]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66,
+          Resource Identifier (URI): Generic Syntax", [[STD66|STD 66]],
-              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+          [[RFC3986|RFC 3986]], DOI 10.17487/RFC3986, January 2005,
-              <https://www.rfc-editor.org/info/rfc3986>.
+          <https://www.rfc-editor.org/info/rfc3986>.
-  [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+[[RFC4648]]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+          Encodings", [[RFC4648|RFC 4648]], DOI 10.17487/RFC4648, October 2006,
-              <https://www.rfc-editor.org/info/rfc4648>.
+          <https://www.rfc-editor.org/info/rfc4648>.
-  [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+[[RFC5234]]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", STD 68, RFC 5234,
+          Specifications: ABNF", [[STD68|STD 68]], [[RFC5234|RFC 5234]],
-              DOI 10.17487/RFC5234, January 2008,
+          DOI 10.17487/RFC5234, January 2008,
-              <https://www.rfc-editor.org/info/rfc5234>.
+          <https://www.rfc-editor.org/info/rfc5234>.
-  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+[[RFC5280]]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
-              Housley, R., and W. Polk, "Internet X.509 Public Key
+          Housley, R., and W. Polk, "Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
+          Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+          (CRL) Profile", [[RFC5280|RFC 5280]], DOI 10.17487/RFC5280, May 2008,
-              <https://www.rfc-editor.org/info/rfc5280>.
+          <https://www.rfc-editor.org/info/rfc5280>.
-  [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+[[RFC5652]]  Housley, R., "Cryptographic Message Syntax (CMS)", [[STD70|STD 70]],
-              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+          [[RFC5652|RFC 5652]], DOI 10.17487/RFC5652, September 2009,
-              <https://www.rfc-editor.org/info/rfc5652>.
+          <https://www.rfc-editor.org/info/rfc5652>.
-  [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+[[RFC6838]]  Freed, N., Klensin, J., and T. Hansen, "Media Type
-              Specifications and Registration Procedures", BCP 13,
+          Specifications and Registration Procedures", [[BCP13|BCP 13]],
-              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+          [[RFC6838|RFC 6838]], DOI 10.17487/RFC6838, January 2013,
-              <https://www.rfc-editor.org/info/rfc6838>.
+          <https://www.rfc-editor.org/info/rfc6838>.
-  [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+[[RFC7230]]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
-              Protocol (HTTP/1.1): Message Syntax and Routing",
+          Protocol (HTTP/1.1): Message Syntax and Routing",
-              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+          [[RFC7230|RFC 7230]], DOI 10.17487/RFC7230, June 2014,
-              <https://www.rfc-editor.org/info/rfc7230>.
+          <https://www.rfc-editor.org/info/rfc7230>.
-  [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+[[RFC7258]]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
-              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+          Attack", [[BCP188|BCP 188]], [[RFC7258|RFC 7258]], DOI 10.17487/RFC7258, May
 , <https://www.rfc-editor.org/info/rfc7258>.
-  [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+[[RFC8126]]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
-              Writing an IANA Considerations Section in RFCs", BCP 26,
+          Writing an IANA Considerations Section in RFCs", [[BCP26|BCP 26]],
-              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+          [[RFC8126|RFC 8126]], DOI 10.17487/RFC8126, June 2017,
-              <https://www.rfc-editor.org/info/rfc8126>.
+          <https://www.rfc-editor.org/info/rfc8126>.
-  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+[[RFC8174]]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
-Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+Key Words", [[BCP14|BCP 14]], [[RFC8174|RFC 8174]], DOI 10.17487/RFC8174,
-              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+          May 2017, <https://www.rfc-editor.org/info/rfc8174>.
-  [SHA2]    Technology, U. N. I. O. S. A., "Secure Hash Standard
+[SHA2]    Technology, U. N. I. O. S. A., "Secure Hash Standard
-              (SHS)", FIPS 180-3, October 2008.
+          (SHS)", FIPS 180-3, October 2008.
-.2.  Informative References
+=== Informative References ===
-  [HTTP]    Nottingham, M., "Building Protocols with HTTP", Work in
+[HTTP]    Nottingham, M., "Building Protocols with HTTP", Work in
-              Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09,
+          Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09,
-              November 1, 2019, <https://tools.ietf.org/html/draft-ietf-
+          November 1, 2019, <https://tools.ietf.org/html/draft-ietf-
-              httpbis-bcp56bis-09>.
+          httpbis-bcp56bis-09>.
-  [JSCEP]    "A Java implementation of the Simple Certificate Enrolment
+[JSCEP]    "A Java implementation of the Simple Certificate Enrolment
-              Protocol", commit 7410332, January 2020,
+          Protocol", commit 7410332, January 2020,
-              <https://github.com/jscep/jscep>.
+          <https://github.com/jscep/jscep>.
-  [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
+[[RFC2634]]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
-              RFC 2634, DOI 10.17487/RFC2634, June 1999,
+          [[RFC2634|RFC 2634]], DOI 10.17487/RFC2634, June 1999,
-              <https://www.rfc-editor.org/info/rfc2634>.
+          <https://www.rfc-editor.org/info/rfc2634>.
-  [RFC4387]  Gutmann, P., Ed., "Internet X.509 Public Key
+[[RFC4387]]  Gutmann, P., Ed., "Internet X.509 Public Key
-              Infrastructure Operational Protocols: Certificate Store
+          Infrastructure Operational Protocols: Certificate Store
-              Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February
+          Access via HTTP", [[RFC4387|RFC 4387]], DOI 10.17487/RFC4387, February
 , <https://www.rfc-editor.org/info/rfc4387>.
-  [RFC5035]  Schaad, J., "Enhanced Security Services (ESS) Update:
+[[RFC5035]]  Schaad, J., "Enhanced Security Services (ESS) Update:
-              Adding CertID Algorithm Agility", RFC 5035,
+          Adding CertID Algorithm Agility", [[RFC5035|RFC 5035]],
-              DOI 10.17487/RFC5035, August 2007,
+          DOI 10.17487/RFC5035, August 2007,
-              <https://www.rfc-editor.org/info/rfc5035>.
+          <https://www.rfc-editor.org/info/rfc5035>.
-  [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+[[RFC7296]]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
-              Kivinen, "Internet Key Exchange Protocol Version 2
+          Kivinen, "Internet Key Exchange Protocol Version 2
-              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+          (IKEv2)", [[STD79|STD 79]], [[RFC7296|RFC 7296]], DOI 10.17487/RFC7296, October
 , <https://www.rfc-editor.org/info/rfc7296>.
-  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+[[RFC8446]]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
-              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+          Version 1.3", [[RFC8446|RFC 8446]], DOI 10.17487/RFC8446, August 2018,
-              <https://www.rfc-editor.org/info/rfc8446>.
+          <https://www.rfc-editor.org/info/rfc8446>.
-  [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+[[RFC8551]]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
-              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+          Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
-              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+          Message Specification", [[RFC8551|RFC 8551]], DOI 10.17487/RFC8551,
-              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
+          April 2019, <https://www.rfc-editor.org/info/rfc8551>.
 Appendix A.  Background Notes
-  This specification has spent over twenty years in the draft stage.
+This specification has spent over twenty years in the draft stage.
-  Its original goal, provisioning IPsec routers with certificates, has
+Its original goal, provisioning IPsec routers with certificates, has
-  long since changed to general device/embedded system/IoT use.  To fit
+long since changed to general device/embedded system/IoT use.  To fit
-  this role, extra features were bolted on in a haphazard manner
+this role, extra features were bolted on in a haphazard manner
-  through the addition of a growing list of appendices and by inserting
+through the addition of a growing list of appendices and by inserting
-  additional, often conflicting, paragraphs in various locations in the
+additional, often conflicting, paragraphs in various locations in the
-  body text.  Since existing features were never updated as newer ones
+body text.  Since existing features were never updated as newer ones
-  were added, the specification accumulated large amounts of historical
+were added, the specification accumulated large amounts of historical
-  baggage over time.  If OpenPGP was described as "a museum of 1990s
+baggage over time.  If OpenPGP was described as "a museum of 1990s
-  crypto", then the SCEP document was its graveyard.
+crypto", then the SCEP document was its graveyard.
-  About five years ago, the specification, which even at that point had
+About five years ago, the specification, which even at that point had
-  seen only sporadic reposts of the existing document, was more or less
+seen only sporadic reposts of the existing document, was more or less
-  abandoned by its original sponsors.  Due to its widespread use in
+abandoned by its original sponsors.  Due to its widespread use in
-  large segments of the industry, the specification was rebooted in
+large segments of the industry, the specification was rebooted in
 , cleaning up fifteen years' worth of accumulated cruft, fixing
-  errors, clarifying ambiguities, and bringing the algorithms and
+errors, clarifying ambiguities, and bringing the algorithms and
-  standards used into the current century (prior to the update, the de
+standards used into the current century (prior to the update, the de
-  facto lowest-common-denominator algorithms used for interoperability
+facto lowest-common-denominator algorithms used for interoperability
-  were the insecure forty-year-old single DES and broken MD5 hash
+were the insecure forty-year-old single DES and broken MD5 hash
-  algorithms).
+algorithms).
-  Note that although the text of the current specification has changed
+Note that although the text of the current specification has changed
-  significantly due to the consolidation of features and appendices
+significantly due to the consolidation of features and appendices
-  into the main document, the protocol that it describes is identical
+into the main document, the protocol that it describes is identical
-  on the wire to the original (with the unavoidable exception of the
+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
+switch from single DES and MD5 to AES and SHA-2).  The only two
-  changes introduced, the "SCEPStandard" indicator in GetCACaps and the
+changes introduced, the "SCEPStandard" indicator in GetCACaps and the
-  failInfoText attribute, are both optional values and would be ignored
+failInfoText attribute, are both optional values and would be ignored
-  by older implementations that don't support them, or can be omitted
+by older implementations that don't support them, or can be omitted
-  from messages if they are found to cause problems.
+from messages if they are found to cause problems.
-  Other changes include:
+Other changes include:
-  *  Resolved contradictions in the text -- for example, a requirement
+*  Resolved contradictions in the text -- for example, a requirement
-      given as a MUST in one paragraph and a SHOULD in the next, a MUST
+  given as a MUST in one paragraph and a SHOULD in the next, a MUST
-      NOT in one paragraph and a MAY a few paragraphs later, a SHOULD
+  NOT in one paragraph and a MAY a few paragraphs later, a SHOULD
-      NOT contradicted later by a MAY, and so on.
+  NOT contradicted later by a MAY, and so on.
-  *  Merged several later fragmentary addenda placed in appendices (for
+*  Merged several later fragmentary addenda placed in appendices (for
-      example, the handling of certificate renewal) with the body of the
+  example, the handling of certificate renewal) with the body of the
-      text.
+  text.
-  *  Merged the "SCEP Transactions" and "SCEP Transport" sections,
+*  Merged the "SCEP Transactions" and "SCEP Transport" sections,
-      since the latter mostly duplicated (with occasional
+  since the latter mostly duplicated (with occasional
-      inconsistencies) the former.
+  inconsistencies) the former.
-  *  Updated the algorithms to ones dating from at least this century.
+*  Updated the algorithms to ones dating from at least this century.
-  *  Did the same for normative references to other standards.
+*  Did the same for normative references to other standards.
-  *  Updated the text to use consistent terminology for the client and
+*  Updated the text to use consistent terminology for the client and
-      CA rather than a mixture of client, requester, requesting system,
+  CA rather than a mixture of client, requester, requesting system,
-      end entity, server, certificate authority, certification
+  end entity, server, certificate authority, certification
-      authority, and CA.
+  authority, and CA.
-  *  Corrected incorrect references to other standards, e.g.,
+*  Corrected incorrect references to other standards, e.g.,
-      IssuerAndSerial -> IssuerAndSerialNumber.
+  IssuerAndSerial -> IssuerAndSerialNumber.
-  *  Corrected errors such as a statement that when both signature and
+*  Corrected errors such as a statement that when both signature and
-      encryption certificates existed, the signature certificate was
+  encryption certificates existed, the signature certificate was
-      used for encryption.
+  used for encryption.
-  *  Condensed redundant discussions of the same topic spread across
+*  Condensed redundant discussions of the same topic spread across
-      multiple sections into a single location.  For example, the
+  multiple sections into a single location.  For example, the
-      description of intermediate CA handling previously existed in
+  description of intermediate CA handling previously existed in
-      three different locations, with slightly different requirements in
+  three different locations, with slightly different requirements in
-      each one.
+  each one.
-  *  Added a description of how pkiMessages were processed, which was
+*  Added a description of how pkiMessages were processed, which was
-      never made explicit in the original specification.  This led to
+  never made explicit in the original specification.  This led to
-      creative interpretations that had security problems but were
+  creative interpretations that had security problems but were
-      employed anyway due to the lack of specific guidance on what to
+  employed anyway due to the lack of specific guidance on what to
-      do.
+  do.
-  *  Relaxed some requirements that didn't serve any obvious purpose
+*  Relaxed some requirements that didn't serve any obvious purpose
-      and that major implementations didn't seem to be enforcing.  For
+  and that major implementations didn't seem to be enforcing.  For
-      example, the requirement that the self-signed certificate used
+  example, the requirement that the self-signed certificate used
-      with a request MUST contain a subject name that matched the one in
+  with a request MUST contain a subject name that matched the one in
-      the PKCS #10 request was relaxed to a SHOULD, because a number of
+  the PKCS #10 request was relaxed to a SHOULD, because a number of
-      implementations either ignored the issue entirely or at worst
+  implementations either ignored the issue entirely or at worst
-      performed some minor action like creating a log entry, after which
+  performed some minor action like creating a log entry, after which
-      they continued anyway.
+  they continued anyway.
-  *  Removed discussion of the transactionID from the security
+*  Removed discussion of the transactionID from the security
-      considerations, since the instructions there were directly
+  considerations, since the instructions there were directly
-      contradicted by the discussion of the use of the transactionID in
+  contradicted by the discussion of the use of the transactionID in
-      Section 5.
+  Section 5.
-  *  Added a requirement that the signed message include the signing
+*  Added a requirement that the signed message include the signing
-      certificate(s) in the signedData certificates field.  This was
+  certificate(s) in the signedData certificates field.  This was
-      implicit in the original specification (without it, the message
+  implicit in the original specification (without it, the message
-      couldn't be verified by the CA) and was handled by the fact that
+  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
+  most PKCS #7/CMS libraries do this by default, but was never
-      explicitly mentioned.
+  explicitly mentioned.
-  *  Clarified sections that were unclear or even made no sense -- for
+*  Clarified sections that were unclear or even made no sense -- for
-      example, the requirement for a "hash on the public key" [sic]
+  example, the requirement for a "hash on the public key" [sic]
-      encoded as a PrintableString.
+  encoded as a PrintableString.
-  *  Renamed "RA certificates" to "intermediate CA certificates".  The
+*  Renamed "RA certificates" to "intermediate CA certificates".  The
-      original document at some point added mention of RA certificates
+  original document at some point added mention of RA certificates
-      without specifying how the client was to determine that an RA was
+  without specifying how the client was to determine that an RA was
-      in use, how the RA operations were identified in the protocol, or
+  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
+  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
+  RA or merely an intermediate CA, as opposed to the default
-      practice of having certificates issued directly from a single root
+  practice of having certificates issued directly from a single root
-      CA certificate.  This update uses the term "intermediate CA
+  CA certificate.  This update uses the term "intermediate CA
-      certificates", since this seems to have been the original intent
+  certificates", since this seems to have been the original intent
-      of the text.
+  of the text.
-  *  Redid the PKIMessage diagram to match what was specified in CMS;
+*  Redid the PKIMessage diagram to match what was specified in CMS;
-      the original diagram omitted a number of fields and nested data
+  the original diagram omitted a number of fields and nested data
-      structures, which meant that the diagram didn't match either the
+  structures, which meant that the diagram didn't match either the
-      text or the CMS specification.
+  text or the CMS specification.
-  *  Removed the requirement for a CertPoll to contain a
+*  Removed the requirement for a CertPoll to contain a
-      recipientNonce, since CertPoll is a client message and will never
+  recipientNonce, since CertPoll is a client message and will never
-      be sent in response to a message containing a senderNonce.  See
+  be sent in response to a message containing a senderNonce.  See
-      also the note in Section 3.3.2.
+  also the note in Section 3.3.2.
-  *  Clarified certificate renewal.  This represents a capability that
+*  Clarified certificate renewal.  This represents a capability that
-      was bolted onto the original protocol with (at best) vaguely
+  was bolted onto the original protocol with (at best) vaguely
-      defined semantics, including a requirement by the CA to guess
+  defined semantics, including a requirement by the CA to guess
-      whether a particular request was a renewal or not.  In response to
+  whether a particular request was a renewal or not.  In response to
-      developer feedback that they either avoided renewal entirely
+  developer feedback that they either avoided renewal entirely
-      because of this uncertainty or hard-coded in particular behaviour
+  because of this uncertainty or hard-coded in particular behaviour
-      on a per-CA basis, this specification explicitly identifies
+  on a per-CA basis, this specification explicitly identifies
-      renewal requests as such and provides proper semantics for them.
+  renewal requests as such and provides proper semantics for them.
-  *  Corrected the requirement that "undefined message types are
+*  Corrected the requirement that "undefined message types are
-      treated as an error", since this negates the effect of GetCACaps,
+  treated as an error", since this negates the effect of GetCACaps,
-      which is used to define new message types.  In particular,
+  which is used to define new message types.  In particular,
-      operations such as GetCACaps "Renewal" would be impossible if
+  operations such as GetCACaps "Renewal" would be impossible if
-      enforced as written, because the Renewal operation was an
+  enforced as written, because the Renewal operation was an
-      undefined message type at the time.
+  undefined message type at the time.
-  *  In line with the above, added IANA registries for several entries
+*  In line with the above, added IANA registries for several entries
-      that had previously been defined in an ad hoc manner in different
+  that had previously been defined in an ad hoc manner in different
-      locations in the text.
+  locations in the text.
-  *  Added the "SCEPStandard" keyword to GetCACaps to indicate that the
+*  Added the "SCEPStandard" keyword to GetCACaps to indicate that the
-      CA complies with the final version of the SCEP standard, since the
+  CA complies with the final version of the SCEP standard, since the
-      definition of what constitutes SCEP standards compliance has
+  definition of what constitutes SCEP standards compliance has
-      changed significantly over the years.
+  changed significantly over the years.
-  *  Added the optional failInfoText attribute to deal with the fact
+*  Added the optional failInfoText attribute to deal with the fact
-      that failInfo was incapable of adequately communicating to clients
+  that failInfo was incapable of adequately communicating to clients
-      why a certificate request operation had been rejected.
+  why a certificate request operation had been rejected.
-  *  Removed the discussion in the security considerations of
+*  Removed the discussion in the security considerations of
-      revocation issues, since SCEP doesn't support revocation as part
+  revocation issues, since SCEP doesn't support revocation as part
-      of the protocol.
+  of the protocol.
-  *  Clarified the use of nonces, which if applied as originally
+*  Clarified the use of nonces, which if applied as originally
-      specified would have made the use of polling in the presence of a
+  specified would have made the use of polling in the presence of a
-      lost message impossible.
+  lost message impossible.
-  *  Removed the discussion of generating a given transactionID by
+*  Removed the discussion of generating a given transactionID by
-      hashing the public key, since this implied that there was some
+  hashing the public key, since this implied that there was some
-      special significance in the value generated this way.  Since it
+  special significance in the value generated this way.  Since it
-      was neither a MUST nor a MAY, it was unsound to imply that servers
+  was neither a MUST nor a MAY, it was unsound to imply that servers
-      could rely on the value being generated a certain way.  In
+  could rely on the value being generated a certain way.  In
-      addition, it wouldn't work if multiple transactions as discussed
+  addition, it wouldn't work if multiple transactions as discussed
-      in Section 4.4 were initiated, since the deterministic generation
+  in Section 4.4 were initiated, since the deterministic generation
-      via hashing would lead to duplicate transactionIDs.
+  via hashing would lead to duplicate transactionIDs.
-  *  Added examples of SCEP messages to give implementers something to
+*  Added examples of SCEP messages to give implementers something to
-      aim for.
+  aim for.
 Acknowledgements
-  The editor would like to thank all of the previous editors, authors,
+The editor would like to thank all of the previous editors, authors,
-  and contributors for their work maintaining the document over the
+and contributors for their work maintaining the document over the
-  years: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy
+years: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy
-  Nourse, Max Pritikin, Jan Vilhuber, and others.  The IETF reviewers
+Nourse, Max Pritikin, Jan Vilhuber, and others.  The IETF reviewers
-  provided much useful feedback that helped improve the document, and
+provided much useful feedback that helped improve the document, and
-  in particular spotted a number of things that were present in SCEP
+in particular spotted a number of things that were present in SCEP
-  through established practice rather than by being explicitly
+through established practice rather than by being explicitly
-  described in the text.  Numerous other people have contributed during
+described in the text.  Numerous other people have contributed during
-  the long life cycle of the document, and all deserve thanks.  In
+the long life cycle of the document, and all deserve thanks.  In
-  addition, several PKCS #7 / CMS libraries contributed to
+addition, several PKCS #7 / CMS libraries contributed to
-  interoperability by doing the right thing despite what earlier SCEP
+interoperability by doing the right thing despite what earlier SCEP
-  documents required.
+documents required.
-  The authors of earlier draft versions of this document would like to
+The authors of earlier draft versions of this document would like to
-  thank Peter William of ValiCert, Inc. (formerly of VeriSign, Inc.),
+thank Peter William of ValiCert, Inc. (formerly of VeriSign, Inc.),
-  Alex Deacon of VeriSign, Inc., and Christopher Welles of IRE, Inc.
+Alex Deacon of VeriSign, Inc., and Christopher Welles of IRE, Inc.
-  for their contributions to early versions of this protocol and this
+for their contributions to early versions of this protocol and this
-  document.
+document.
 Author's Address
-  Peter Gutmann
+Peter Gutmann
-  University of Auckland
+University of Auckland
-  Department of Computer Science
+Department of Computer Science
-  Auckland
+Auckland
-  New Zealand
+New Zealand
+Email: [email protected]
-  Email: [email protected]
+[[Category:Informational]]

Anonymous

Search

Difference between revisions of "RFC8894"

Latest revision as of 11:22, 30 October 2020

Contents

Introduction

Conventions Used in This Document

SCEP Overview

SCEP Entities

Client

Certificate Authority

CA Certificate Distribution

Client Authentication

Enrolment Authorisation

Certificate Enrolment/Renewal

Client State Transitions

Certificate Access

CRL Access

Certificate Revocation

Mandatory-to-Implement Functionality

SCEP Secure Message Objects

SCEP Message Object Processing

SCEP pkiMessage

Signed Transaction Attributes

transactionID

messageType

pkiStatus

failInfo and failInfoText

senderNonce and recipientNonce

SCEP pkcsPKIEnvelope

SCEP pkiMessage types

PKCSReq/RenewalReq

CertRep

CertRep SUCCESS

CertRep FAILURE

CertRep PENDING

CertPoll (GetCertInitial)

GetCert and GetCRL

Degenerate certificates-only CMS SignedData

CA Capabilities

GetCACaps HTTP Message Format

CA Capabilities Response Format

SCEP Transactions

HTTP POST and GET Message Formats

Get CA Certificate

Get CA Certificate Response Message Format

CA Certificate Response Message Format

CA Certificate Chain Response Message Format

Certificate Enrolment/Renewal

Certificate Enrolment/Renewal Response Message

Poll for Client Initial Certificate

Polling Response Message Format

Certificate Access

Certificate Access Response Message Format

CRL Access

CRL Access Response Message Format

Get Next Certificate Authority Certificate

Get Next CA Response Message Format

SCEP Transaction Examples

Successful Transactions

Transactions with Errors

IANA Considerations

Registration of the application/x-x509-ca-cert Media Type

Registration of the application/x-x509-ca-ra-cert Media Type

Registration of the application/x-x509-next-ca-cert Media Type

Registration of the application/x-pki-message Media Type

Security Considerations

General Security

Use of the CA Private Key

ChallengePassword Shared Secret Value

Lack of Certificate Issue Confirmation

GetCACaps Issues

Lack of PoP in Renewal Requests

Traffic Monitoring

Unnecessary Cryptography

Use of SHA-1

References

Normative References

Informative References

Navigation