pkiMessage {
  contentType = signedData
  content {
    pkcsPKIEnvelope {   -- Optional
      contentType = envelopedData
      content {
        recipientInfo
        contentType = data
        content {
          messageData   -- Typically PKCS #10 request
          }
        }
      }
    signerInfo {
      signedAttrs {
        transactionID
        messageType
        pkiStatus
        failInfo
        senderNonce
        recipientNonce
        }
      signature
      }
    }
  }

		

Figure 2: 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.1.2).

Note: The remainder of this document will refer only to 'messageData', but it is understood to always be encapsulated in the pkcsPKIEnvelope (Section 3.1.2). The format of the data in the messageData is defined by the messageType attribute (see Section 3.1) of the Signed-Data. If there is no messageData to be transmitted, the entire pkcsPKIEnvelope MUST be omitted.

3.1. SCEP pkiMessage

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

• The contentType in contentInfo MUST be data ({pkcs-7 1}) as defined in CMS [CMS].
• The signed content, if present (e.g. FAILURE and PENDING CertRep messages will lack any signed content), MUST be a pkcsPKIEnvelope (Section 3.1.2), and MUST match the messageType attribute.
• The SignerInfo MUST contain a set of authenticatedAttributes (see CMS [CMS] as well as Section 3.1 in this document).

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

• A transactionID attribute (see Section 3.1.1.1).
• A messageType attribute (see Section 3.1.1.2).
• A senderNonce attribute (see Section 3.1.1.5).
• Any attributes required by CMS [CMS].

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

• A pkiStatus attribute (see Section 3.1.1.3).
• A recipientNonce attribute (see Section 3.1.1.5).

3.1.1. Signed Transaction Attributes

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

Attribute	Encoding	Comment
transactionID	PrintableString	Unique ID for this transaction as a text string
messageType	PrintableString	Decimal value as a numeric text string
pkiStatus	PrintableString	Decimal value as a numeric text string
failInfo	PrintableString	Decimal value as a numeric text string
senderNonce	OCTET STRING	Random nonce as a 16-byte binary data string
recipientNonce	OCTET STRING	Random nonce as 16-byte binary data string

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

The attributes are detailed in the following sections.

3.1.1.1. transactionID

A PKI operation is a transaction consisting of the messages exchanged between a requester and the server. The transactionID is a text string generated by the client when starting a transaction. The client MUST generate a unique string as the transaction identifier, which MUST be used for all PKI messages exchanged for a given enrolment, encoded as a PrintableString.

One means of generating the transactionID is as a SHA-1, SHA-256, or SHA-512 hash of the public key value in the enrolment request when encoded as an X.509 SubjectPublicKeyInfo [PKIX] (in other words the exact binary form in which it appears in both the request and the resulting certificate) and then coverting it into a text string using base64 encoding or ASCII hex digits. This allows the SCEP client to automatically generate the same transactionID for any given public key. The SCEP protocol requires that transactionIDs be unique, so that subsequent polling queries can be matched with previous transactions. When separate signing and encryption certificates are requested by the client, using distinct keypairs ensures that distinct transactionIDs are also used when the transactionID is created by hashing the X.509 SubjectPublicKeyInfo.

    [Question: Again with the separate-certificate stuff...].

When using the certificate query and CRL query messages defined in this protocol, the transactionID is required so that the requester can match the response message with the outstanding request message. For a non-enrolment message (for example GetCert and GetCRL), the transactionID SHOULD be some value unique to the client.

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

• CertRep ("3") -- Response to certificate or CRL request.
• RenewalReq ("17") -- PKCS #10 [PKCS10] certificate request for renewal of an existing certificate.
• UpdateReq ("18") -- PKCS #10 [PKCS10] certificate request for update of a certificate issued by a different CA.
• PKCSReq ("19") -- PKCS #10 [PKCS10] certificate request.
• CertPoll ("20") -- Certificate polling in manual enrolment.
• GetCert ("21") -- Retrieve a certificate.
• GetCRL ("22") -- Retrieve a CRL.

Undefined message types are treated as an error.

3.1.1.3. pkiStatus

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

• SUCCESS ("0") -- request granted.
• FAILURE ("2") -- request rejected. When pkiStatus is FAILURE, the failInfo attribute, as defined in Section 3.1.1.4, MUST also be present.
• PENDING ("3") -- request pending for manual approval.

Undefined pkiStatus attributes are treated as an error.

3.1.1.4. failInfo

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

• badAlg ("0") -- Unrecognized or unsupported algorithm identifier.
• badMessageCheck ("1") -- integrity check failed.
• badRequest ("2") -- transaction not permitted or supported.
• badTime ("3") -- The signingTime attribute from the CMS [CMS] authenticatedAttributes was not sufficiently close to the system time (see Section 3.1.1.6).
• badCertId ("4") -- No certificate could be identified matching the provided criteria.

    [Question: Is there any demand for a free-form UTF8String 
     attribute to explain what really went wrong?  Trying to sort 
     out an error when all you ever get back is the near-universal 
     badRequest is almost impossible, adding a failInfoText 
     attribute to address this could be quite useful since it 
     would allow expressing information such as a failure to meet 
     CA policy, or indeed anything more complex than "no go away"].

Undefined failInfo attributes are treated as an error.

3.1.1.5. senderNonce and recipientNonce

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

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

  [Question: What does this do for polling?  Polling messages can 
   get lost so nonces will go out of sync, is there a need to 
   chain XXXReqs to polls via nonces?  If not, why do we have two 
   nonces?].

3.1.2. SCEP pkcsPKIEnvelope

The information portion of a SCEP message is carried inside an Enveloped-Data content type, as defined in CMS [CMS], with the following restrictions:

• contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as defined in CMS [CMS].
• encryptedContent MUST be the SCEP message being transported (see Section 4), and must match the messageType authenticated Attribute in the pkiMessage.

The CMS [CMS] content-encryption key is encrypted using the public key of the recipient of the message, i.e. the RA or the CA public key (if sent from the requester), or the requester public key (if sent as a reply to the requester).

3.2. SCEP pkiMessage types

All of the messages in this section are pkiMessages (Section 3.1), 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.

3.2.1. PKCSReq/RenewalReq/UpdateReq

The messageData for this type consists of a PKCS #10 [PKCS10] Certification Request. The certification request MUST contain at least the following items:

• The subject Distinguished Name.
• The subject public key.
• For a PKCSReq and if authorisation based on a password is being used, a challengePassword attribute.

In addition to the authenticatedAttributes required for a valid CMS [CMS] message, the pkiMessage MUST include the following attributes:

• A transactionID (Section 3.1.1.1) attribute.
• A messageType (Section 3.1.1.2) attribute set to PKCSReq, RenewalReq, or UpdateReq as appropriate.
• A senderNonce (Section 3.1.1.5) attribute.

The pkcsPKIEnvelope for this message type is protected using the public key of the recipient as detailed in Section 3.1.2, e.g. either the CA or RA public key.

3.2.2. CertRep

The messageData for this type consists of a degenerate certificates-only CMS [CMS] Signed-Data message (Section 3.3). The exact content required for the reply depends on the type of request this message is a reply to. They are detailed in Section 3.2.2.1 and in Section 4.

In addition to the authenticatedAttributes required for a valid CMS [CMS], this pkiMessage MUST include the following attributes:

• The transactionID (Section 3.1.1.1) attribute copied from the request we are responding to.
• A messageType (Section 3.1.1.2) attribute set to CertRep.
• A senderNonce (Section 3.1.1.5) attribute.
• A recipientNonce attribute (Section 3.1.1.5) copied from the senderNonce from the request that this is a response to.
• A pkiStatus (Section 3.1.1.3) set to the status of the reply.

The pkcsPKIEnvelope for this message type is protected using the public key of the recipient as detailed in Section 3.1.2. For example if a self-signed certificate was used to send the original request then this self-signed certificate's public key is used to encrypt the content-encryption key of the SUCCESS response's pkcsPKIEnvelope.

Note that although it may appear that the senderNonce serves no purpose in this message, it is required if the CertRep contains a PENDING status since the nonce will be used in subsequent polling operations.

3.2.2.1. CertRep SUCCESS

When the pkiStatus attribute is set to SUCCESS, the messageData for this message consists of a degenerate certificates-only CMS [CMS] Signed-Data message (Section 3.3). The content of this degenerate certificates-only Signed-Data depends on what the original request was, as outlined below.

Request-type	Reply-contents
PKCSReq	The reply MUST contain at least the issued certificate in the certificates field of the Signed-Data. The reply MAY contain additional certificates, but the issued certificate MUST be the leaf certificate. The reply MUST NOT contain a CRL.
RenewalReq	Same as PKCSReq
UpdateReq	Same as PKCSReq
CertPoll	Same as PKCSReq
GetCert	The reply MUST contain at least the requested certificate in the certificates field of the Signed-Data. The reply MAY contain additional certificates, but the requested certificate MUST be the leaf certificate. The reply MUST NOT contain a CRL.
GetCRL	The reply MUST contain the CRL in the crls field of the Signed-Data. The reply MUST NOT contain a certificate.

3.2.2.2. CertRep FAILURE

When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a failInfo (Section 3.1.1.4) attribute set to the appropriate error condition describing the failure. The pkcsPKIEnvelope (Section 3.1.2) MUST be omitted.

3.2.2.3. CertRep PENDING

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

3.2.3. CertPoll (GetCertInitial)

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

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.

In addition to the authenticatedAttributes required for a valid CMS [CMS], this pkiMessage MUST include the following attributes:

• The same transactionID (Section 3.1.1.1) attribute from the original PKCSReq/RenewalReq/UpdateReq message.
• A messageType (Section 3.1.1.2) attribute set to CertPoll.
• A senderNonce (Section 3.1.1.5) attribute.
• A recipientNonce attribute (Section 3.1.1.5) copied from the senderNonce from the request that this is a response to.

3.2.4. GetCert

The messageData for this type consists of an IssuerAndSerialNumber as defined in CMS [CMS] which uniquely identifies the certificate being requested.

In addition to the authenticatedAttributes required for a valid CMS [CMS], this pkiMessage MUST include the following attributes:

• A transactionID (Section 3.1.1.1) attribute.
• A messageType (Section 3.1.1.2) attribute set to GetCert.
• A senderNonce (Section 3.1.1.5) attribute.

A self-signed certificate MAY be used in the signed envelope. This enables the requester to request their own certificate if they were unable to store it previously.

3.2.5. GetCRL

The messageData for this type consists of a IssuerAndSerialNumber as defined in CMS [CMS] containing the issuer name and serial number of the certificate whose revocation status is being checked.

In addition to the authenticatedAttributes required for a valid CMS [CMS], this pkiMessage MUST include the following attributes:

• A transactionID (Section 3.1.1.1) attribute.
• A messageType (Section 3.1.1.2) attribute set to GetCRL.
• A senderNonce (Section 3.1.1.5) attribute.

3.3. Degenerate certificates-only CMS Signed-Data

CMS [CMS] includes a degenerate case of the CMS [CMS] Signed-Data content type, in which there are no signers. The use of such a degenerate case is to disseminate certificates and CRLs. For SCEP the content field of the ContentInfo value of a degenerate certificates-only Signed-Data MUST be omitted.

When carrying certificates, the certificates are included in the 'certificates' field of the Signed-Data. When carrying a CRL, the CRL will be included in the 'crls' field of the Signed-Data.

3.4. CA Capabilities

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

3.4.1. GetCACaps HTTP Message Format

This message requests capabilities from a CA, with the format:

"GET" CGI-PATH CGI-PROG "?operation=GetCACaps" \
      [ "&message=" CA-IDENT ]

		    

with the message components as described in Section 5 (note that the message component is optional and is only required if multiple CAs are being operated through the same server). The response is a list of text capabilities, as defined in Section 3.4.2. CA servers SHOULD support the GetCACaps message and MUST support it when they implement any extended functonality beyond the mandatory-to-implement basics Section 2.8.

3.4.2. CA Capabilities Response Format

The response for a GetCACaps message is a list of CA capabilities, in plain text, separated by <LF> characters, as follows (quotation marks are NOT sent):

Keyword	Description
"AES"	CA Supports the AES encryption algorithm.
"DES3"	CA Supports the triple DES encryption algorithm.
"GetNextCACert"	CA Supports the GetNextCACert message.
"POSTPKIOperation"	PKIOPeration messages may be sent via HTTP POST.
"Renewal"	CA Supports the Renewal CA operation.
"SHA-1"	CA Supports the SHA-1 hashing algorithm.
"SHA-256"	CA Supports the SHA-256 hashing algorithm.
"SHA-512"	CA Supports the SHA-512 hashing algorithm.
"Update"	CA Supports the Update CA operation.

The client SHOULD use SHA-256 or SHA-512 in preference to SHA-1 hashing, and AES in preference to triple DES if they are supported by the CA.

Announcing some of these capabilities is redundant since they're required as mandatory-to-implement functionality (see Section 2.8), but it may be useful to announce them in order to deal with old implementations that would otherwise default to obsolete, insecure algorithms and mechanisms.

The server MUST use the texual case specified here, but clients SHOULD ignore the textual case when processing this message. A client MUST be able to accept and ignore any unknown keywords that might be sent back by a CA.

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

(Note that at least one widely-deployed server implementation supports several of the above operations but doesn't support the GetCACaps message to indicate that it supports them. This means that the equivalent of GetCACaps must be performed through server fingerprinting, which can be done using the ID string "Microsoft-IIS").

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

Example:

GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca

		    

might return:

AES
SHA-256
GetNextCACert
POSTPKIOperation

		    

This means that the CA supports modern crypto algorithms, the GetNextCACert message, and allows PKIOperation messages (PKCSReq/RenewalReq/UpdateReq, GetCert, CertPoll, ...) to be sent using HTTP POST.

4. SCEP Transactions

This section describes the SCEP Transactions, without explaining the transport. The transport of each message is discussed in Section 5. Some of the transaction-requests have no data to send, i.e. the only data is the message-type itself (e.g. a GetCACert message has no additional data).

In this section, each SCEP transaction is specified in terms of the complete messages exchanged during the transaction.

4.1. Get CA Certificate

To get the CA certificate(s), the requester sends a GetCACert message to the server. There is no request data associated with this message (see Section 5.2.1).

4.1.1. Get CA Certificate Response Message Format

The response depends on whether the responding server has RA certificates or only a single CA certificate. The server MUST indicate which response it is sending via the transport protocol used (see Section 5.2.1).

All returned certificates MUST conform to PKIX [PKIX].

If the requester does not have a certificate path to a trust anchor certificate, the SHA-1, SHA-256, or SHA-512 fingerprint of the returned CA certificate (communicated via out-of-band means) may be used to verify it.

4.1.1.1. CA Certificate Response Message Format

If the server does not have any RA Certificates, the response consists of a single X.509 CA certificate.

4.1.1.2. CA/RA Certificate Response Message Format

If the server has RA Certificates, the response consists of a degenerate certificates-only CMS [CMS] Signed-Data (Section 3.3) containing the CA and RA certificates, with the RA certificate(s) as the leaf certificate(s).

4.2. Certificate Enrolment/Renewal/Update

A PKCSReq/RenewalReq/UpdateReq (Section 3.2.1) message is used to perform a certificate enrolment, renewal, or update transaction.

The reply MUST be a CertRep (Section 3.2.2) message sent back from the server, indicating SUCCESS, FAILURE, or PENDING.

Precondition: Both the requester and the certification authority have completed their initialization process. The requester has already been configured with the CA/RA certificate.

Postcondition: The requester receives the certificate, the request is rejected, or the request is pending. A pending response might indicate that manual authentication is necessary.

4.2.1. Certificate Enrolment/Renewal/Update Response Message

If the request is granted, a CertRep (Section 3.2.2) message with pkiStatus set to SUCCESS is returned. The reply MUST also contain the certificate (and MAY contain any other certificates needed by the requester). The issued certificate MUST be the first in the list.

If the request is rejected, a CertRep (Section 3.2.2) message with pkiStatus set to FAILURE is returned. The reply MUST also contain a failInfo attribute.

If the the CA is configured to manually authenticate the requester, a CertRep (Section 3.2.2) message with pkiStatus set to PENDING MAY be returned. The CA MAY return a PENDING for other reasons.

4.3. Poll for Requester Initial Certificate

Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, a requester will enter the polling state by periodically sending CertPoll messages (Section 3.2.3) to the server, until either the request is granted and the certificate is sent back, or the request is rejected, or some preconfigured time limit for polling or maximum number of polls is exceeded.

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

Since at this time the certificate has not been issued, the requester can only use its own subject name (which was contained in the original PKCS# 10 sent via PKCSReq/RenewalReq/UpdateReq) to identify the polled certificate request. In theory there can be multiple outstanding requests from one requester (for example, if different keys and different key-usages were used to request multiple certificates), so the transactionID must also be included to disambiguate between multiple requests. In practice however it's safer for the requester to not have multiple requests outstanding at any one time, since this tends to confuse some servers.

PreCondition: The requester has received a CertRep with pkiStatus set to PENDING.

PostCondition: The requester has either received a valid response, which could be either a valid certificate (pkiStatus = SUCCESS), or a FAILURE message, or the polling period times out.

4.3.1. Polling Response Message Format

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

4.4. Certificate Access

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

This transaction consists of one GetCert (Section 3.2.4) message sent to the server by a requester, and one CertRep (Section 3.2.2) message sent back from the server.

PreCondition: The certification authority has issued the queried certificate and the issuer assigned serial number is known.

PostCondition: Either the certificate is sent back or the request is rejected.

4.4.1. Certificate Access Response Message Format

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

4.5. CRL Access

Clients can request a CRL from the SCEP server as described in Section 2.6.

PreCondition: The certification authority certificate has been downloaded to the end entity.

PostCondition: CRL sent back to the requester.

4.5.1. CRL Access Response Message Format

The CRL is sent back to the requester in a CertRep (Section 3.2.2) message. The information portion of this message is a degenerate certificates-only Signed-Data (Section 3.3) that contains only the most recent CRL in the crls field of the Signed-Data.

4.6. Get Next Certification Authority Certificate

When the CA certificate expires all certificates that have been signed by it are no longer valid. CA key rollover provides a mechanism by which the server MAY distribute a new CA certificate which is valid in the future; when the current certificate has expired. When a CA certificate is about to expire, clients need to retrieve the CA's next CA certificate (i.e. the rollover certificate). This is done via the GetNextCACert message. There is no request data associated with this message (see Section 5.2.6).

Clients MUST store the not-yet-valid CA certificate, and any not-yet-valid client certificates obtained, until such time that they are valid, at which point clients switch over to using the newly valid certificates.

4.6.1. Get Next CA Response Message Format

The response consists of a Signed-Data CMS [CMS], signed by the current CA (or RA) signing key. Clients MUST validate the signature on the the Signed-Data CMS [CMS] before accepting any of its contents.

The content of the Signed-Data CMS [CMS] message is a degenerate certificates-only Signed-Data (Section 3.3) message containing the new CA certificate and any new RA certificates, as defined in Section 5.2.1.1.2, to be used when the current CA certificate expires.

If the CA (or RA) does not have the rollover certificate(s) it MUST reject the request. It SHOULD also remove the GetNextCACert setting from the capabilities until it does have rollover certificates.

If there are any RA certificates in this response, clients MUST check that these RA certificates are signed by the CA, and MUST check authorization of these RA certificates (see Section 2.1.3).

5. SCEP Transport

HTTP [HTTP] is used as the transport protocol for SCEP Message Objects.

5.1. HTTP GET and POST Message Formats

SCEP uses the HTTP "GET" and "POST" messages to exchange information with the CA. The following defines the syntax of a HTTP GET and POST messages sent from a requester to a certification authority server:

"GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE
"POST" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE

		  

where:

• CGI-PATH defines the actual CGI path to invoke the CGI program that parses the request.
• CGI-PROG is set to be the string "pkiclient.exe". This is intended to be the program that the CA will use to handle the SCEP transactions, though the CA may ignore CGI-PROG and use only the CGI-PATH, or ignore both if it's not issuing certificates via a web server. Typically, setting CGI-PATH/CGI-PROG to "/cgi-bin/pkiclient.exe" will satisfy most servers.
• OPERATION depends on the SCEP transaction and is defined in the following sections.
• MESSAGE depends on the SCEP transaction and is defined in the following sections.

Early SCEP drafts performed all communications via "GET" messages, including non-idempotent ones that should have been sent via "POST" messages. This has caused problems because of the way that the (supposedly) idempotent GET interacts with caches and proxies, and because the extremely large GET requests created by encoding CMS messages may be truncated in transit. These issues are typically not visible when testing on a LAN, but crop up during deployment over WANs. If the remote CA supports it, any of the CMS [CMS]-encoded SCEP messages SHOULD be sent via HTTP POST instead of HTTP GET. This is allowed for any SCEP message except GetCACert, GetNextCACert, or GetCACaps, and avoids the need for base64- and URL-encoding that's required for GET messaging. The client can verify that the CA supports SCEP messages via POST by looking for the "POSTPKIOperation" capability (See Section 3.4.2).

When using GET messages to communicate binary data, base64 encoding as specified in [2] 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 [8] in addition to being bas64 encoded.

5.1.1. Response Message Format

For each GET or POST operation, the CA/RA server MUST return a Content-Type and appropriate response data, if any.

5.2. SCEP HTTP Messages

This section describes the OPERATION and MESSAGE values for SCEP exchanges.

5.2.1. GetCACert

The OPERATION MUST be set to "GetCACert".

The MESSAGE MAY be omitted, or it MAY be a string that represents the certification authority issuer identifier, allowing for multiple CAs supported by one SCEP server.

5.2.1.1. GetCACert Response

The response for GetCACert is different between the case where the CA directly communicates with the requester during the enrolment, and the case where a RA exists and the requester communicates with the RA during the enrolment.

5.2.1.1.1. CA Certificate Only Response

The response will have a Content-Type of "application/x-x509-ca-cert".

The body of this response consists of an X.509 CA certificate, as defined in Section 4.1.1.1:

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

<binary X.509>

				

5.2.1.1.2. CA and RA Certificates Response

The response will have a Content-Type of "application/x-x509-ca-ra-cert".

The body of this response consists of a degenerate certificates-only CMS [CMS] Signed-Data (Section 3.3) message containing both CA and RA certificates, as defined in Section 4.1.1.2:

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

<binary CMS>

				

5.2.2. PKCSReq/RenewalReq/UpdateReq

The OPERATION MUST be set to "PKIOperation".

The MESSAGE consists of a PKCSReq, RenewalReq, or UpdateReq SCEP message. When implemented using HTTP POST this might look as follows:

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

<binary CMS data>

			  

When implemented using HTTP GET this might look as follows:

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

			  

5.2.2.1. PKCSReq/RenewalReq/UpdateReq Response

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

The body of this response consists of a CertRep SCEP message defined in Section 4.2.1. The following is an example of the response:

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

<binary CertRep msg>

			  

5.2.3. CertPoll

The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a CertPoll SCEP message.

5.2.3.1. CertPoll Response

The body of this response consists of a CertRep SCEP message defined in Section 4.3.1.

5.2.4. GetCert

The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a GetCert SCEP message.

5.2.4.1. GetCert Response

The body of this response consists of a CertRep SCEP message defined in Section 4.4.1.

5.2.5. GetCRL

The OPERATION MUST be set to "PKIOperation". The MESSAGE consists of a GetCRL SCEP message.

5.2.5.1. GetCRL Response

The body of this response consists of a CertRep SCEP message defined in Section 4.5.1.

5.2.6. GetNextCACert

The OPERATION MUST be set to "GetNextCACert".

The MESSAGE MAY be ommitted, or it MAY be a string that represents the certification authority issuer identifier, if such has been set by the CA Administrator.

5.2.6.1. GetNextCACert Response

The response will have a Content-Type of "application/x-x509-next-ca-cert".

The body of this response consists of a Signed-Data CMS [CMS], as defined in Section 4.6.1. (This is similar to the GetCert response but does not include any of the attributes defined in Section 3.1.1).

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

<binary CMS>

			  

6. Contributors/Acknowledgements

The editor would like to thank all the previous editors, authors and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, etc for their work maintaining the draft over the years. Numerous other people have contributed during the long life cycle of the draft and all deserve thanks.

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

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

The security goals of SCEP are that no adversary can:

• Subvert the public key/identity binding from that intended.
• Discover the identity information in the enrolment requests and issued certificates.
• Cause the revocation of certificates with any non-negligible probability.

Here an adversary is any entity other than the requester and the CA (and optionally the RA) participating in the protocol. The adversary is computationally limited, but that can manipulate data during transmission (that is, can act as a MITM). The precise meaning of 'computationally limited' depends on the implementer's choice of one-way hash functions and cryptographic algorithms.

The first and second goals are met through the use of CMS [CMS] and PKCS #10 [PKCS10] encryption and digital signatures using authenticated public keys. The CA's public key is authenticated via out-of-band means such as the checking of the CA fingerprint, as specified in Section 2.1.2, and the SCEP client's public key is authenticated through manual or pre-shared secret authentication, as specified in Section 2.2. The third goal is met through the use of a challengePassword for revocation, which is chosen by the SCEP client and communicated to the CA protected by the CMS [CMS] Enveloped-Data, as specified in Section 2.7.

    [Question: Uhh, the protocol doesn't support revocation 
     requests, should this be removed to match what it actually 
     does or should be spec be updated to match the description 
     here?].

The motivation of the first security goal is straightforward. The motivation for the second security goal is to protect the identity information in the enrolment requests and issued certificates. Subsequent protocols can use the certificate in ways that either expose the identity information, or protect it, depending on the security requirements of those protocols. The motivation for the third security goal is to protect the SCEP clients from denial of service attacks.

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

8.2. Use of the CA keypair

A CA key pair is generally meant for (and is usually flagged as) certificate (and CRL) signing exclusively, rather than data signing or encryption. The SCEP protocol, however, uses the CA private key to both encrypt and sign CMS [CMS] transport messages. This is generally considered undesirable, as it widens the possibility of an implementation weakness, and provides:

• Another place that the private key must be used (and hence is slightly more vulnerable to exposure).
• Another place where a side channel attack (say, timing or power analysis) might be used.
• Another place that the attacker might somehow insert their own data and get it signed by the CA's private key (note that this issue is purely theoretical, since the CMS data signed by the CA is nothing remotely like a certificate and couldn't be passed off as such).

One solution to this problem is to use RA keys to secure the SCEP transport (i.e. message signing and encrypting), which allows the CA keys to be used only for their intended purpose of certificate signing. An RA can be implemented in two ways, physically separate or implicit. In the implicit case, the CA simply creates an extra key pair. A physically separate RA allows the CA to be inside the secure network, not accessible to hackers at all.

The corresponding downside of using an RA is that it makes the client side considerably more complex, as the key used by the CA to issue certificates is no longer the same one used by the client to communicate with the CA. This requires that the client keep track of multiple keys rather than a single CA key.

8.3. Challenge Password

The challengePassword sent in the PKCS #10 enrolment request is signed and encrypted by way of being encapsulated in a pkiMessage. When saved by the CA, care should be taken to protect this password.

If the challengePassword is used to automatically authenticate an enrolment request, it is recommended that some form of one-time password be used to minimize damage in the event the data is compromised.

8.4. Transaction ID

CAs/RAs SHOULD NOT rely on the transactionID to be correct or as specified in this document. Requesters with buggy software might add additional undetected duplicate requests to the CA's queue. A well-written CA/RA should never assume the data from a requester is well-formed.

8.5. Nonces and Replay

In order to detect replay attacks, both sides need to maintain state information sufficient to detect an unexpected nonce value.

8.6. GetCACaps Issues

The GetCACaps response is not signed. This allows an attacker to perform downgrade attacks on the cryptographic capabilities of the client/CA exchange.

8.7. Unnecessary cryptography

Some of the SCEP exchanges use signing and encryption operations that are not necessary. In particular the GetCert and GetCRL exchanges are encrypted and signed in both directions. The information requested is public and thus signing the requests is of questionable value but also CRLs and Certificates, i.e. the respective responses, are already signed by the CA and can be verified by the recipient without requiring additional signing and encryption.

This may affect performance and scalability of the CA and could be used as an attack vector on the CA (though not an anonymous one). The use of CRLDPs as well as other ways of retrieving certificates such as HTTP access and LDAP are recommended for CRL access.

8.8. GetNextCACert

GetNextCACert depends on a 'flag moment' at which every client in the PKI infrastructure switches from the current CA certificate (and client certificate) to the new CA certificate and client certificates. Proper monitoring of the network infrastructure can ensure that this will proceed as expected but any errors in processing or implementation can result in a failure of the PKI infrastructure.

9. References

9.1. Normative References

[1]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]	Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[3]	Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[4]	Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5]	Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[6]	Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[7]	Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 5280, May 2008.
[8]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

9.2. Informative References

[9]	Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[10]	Adams, C., Farrell, S., Kause, T. and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[11]	Gutmann, P., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, February 2006.
[12]	Kaufman, C., "The Internet Key Exchange (IKEv2)", RFC 4306, December 2005.
[13]	Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[14]	Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Appendix A. SCEP State Transitions

SCEP state transitions are indexed by the transactionID attribute. The design goal is to ensure the synchronization between the CA and the requester under various error situations.

Each enrolment transaction is uniquely associated with a transactionID (carried in the transactionID signed attribute (see Section 3.1.1.1). Because the enrolment transaction could be interrupted by various errors, including network connection errors or client reboot, the SCEP client generates a fixed transaction identifier as specified in Section 3.1.1.1 which is included in the PKCSReq/RenewalReq/UpdateReq. If the CA returns a response of PENDING, the requester will poll by periodically sending a CertPoll with the same transaction identifier until either a response other than PENDING is obtained or the configured maximum time has elapsed. This mechanism retains the same transaction identifier throughout the enrolment transaction.

If the client times out or reboots, the client administrator will start another transaction with the same key pair. The second enrolment will have the same transactionID. At the server side, instead of accepting the PKCSReq/RenewalReq/UpdateReq as a new request, it can respond as if another CertPoll message had been sent with that transaction ID. The second PKCSReq/RenewalReq/UpdateReq should be taken as a resynchronization message to allow the process to resume as the same transaction.

The following gives several examples of client to CA transactions.

Client actions are indicated in the left column, CA actions are indicated in the right column. A blank action signifies that no message was received.

The first transaction, for example, would read like this:

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

Successful Enrolment Case: no manual authentication

PKCSReq (1)             ----------> CA Signs Cert
Client Installs Cert    <---------- CertRep (1) SIGNED CERT

		

Successful Enrolment Case: manual authentication required

PKCSReq (10)            ----------> Cert Request goes into Queue
Client Polls            <---------- CertRep (10) PENDING
CertPoll (10)           ----------> Still pending
Client Polls            <---------- CertRep (10) PENDING
CertPoll (10)           ----------> Still pending
Client Polls            <---------- CertRep (10) PENDING
CertPoll (10)           ----------> Still pending
Client Polls            <---------- CertRep (10) PENDING
CertPoll (10)           ----------> Cert has been signed
                        <---------- CertRep (10) SIGNED CERT
Client Installs Cert

		

Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants the certificate and returns SUCCESS, with the certificate. The SUCCESS gets lost:

PKCSReq (3)           ----------> Cert Request goes into queue
                      <---------- CertRep (3) PENDING
CertPoll (3)          ----------> Still pending
                      <---------- CertRep (3) PENDING
CertPoll (3)          ----------> Cert has been signed
                        X-------- CertRep(3) SIGNED CERT
(Time Out)
PKCSReq (3)           ----------> Cert already granted
                      <---------- CertRep (3) SIGNED CERT
Client Installs Cert

		

Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply gets lost:

PKCSReq (3)           ----------> Cert Request goes into queue
                        X-------- CertRep (3) PENDING
(Time Out)
PKCSReq (3)           ---------->
                      <---------- CertRep (3) PENDING
etc...

		

Case when the Certificate is lost, the CA arbitrarily refuses to sign a replacement (enforcing name-uniqueness) until the original certificate has been revoked (there is no change of name information):

PKCSReq (4)           ----------> CA Signs Cert
                      <---------- CertRep (4) SIGNED CERT
Client Installs Cert
(Client looses Cert)
PKCSReq (5)           ----------> There is already a valid cert with
                                  this DN.
                      <---------- CertRep (5) BAD REQUEST
                                  Admin Revokes
PKCSReq (5)           ----------> CA Signs Cert
                      <---------- CertRep (5) SIGNED CERT
Client Installs Cert

		

CA certificate rollover case:

GetNextCACert         ---------->
                      <---------- New CA certificate

PKCSReq*              ----------> CA Signs certificate with NEW 
                                  key
Client Stores Cert    <---------- CertRep - Certificate issued
for installation when             from NEW CA certificate and key 
existing cert expires.            pair

		

*enveloped for new CA or RA cert and key pair. The CA will use the envelope to determine which key and certificate to use to issue the client certificate.

Appendix B. Background Notes

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

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

Other changes include:

• Resolved contradictions in the text, for example a requirement given as a MUST in one paragraph and a SHOULD in the next, a MUST NOT in one paragraph and a MAY a few paragraphs later, a SHOULD NOT contradicted later by a MAY, and so on.
• Merged several later fragmentary addenda placed in appendices (for example the handling of certificate renewal and update) with the body of the text.
• Updated the algorithms to ones dating from at least this century.
• Did the same for normative references to other standards.
• Corrected incorrect references to other standards, e.g. IssuerAndSerial -> IssuerAndSerialNumber.
• Corrected errors such as a statement that when both signature and encryption certificates existed, the signature certificate was used for encryption.
• Condensed redundant discussions of the same topic spread across multiple sections into a single location. For example the description of RA certificate handling previously existed in three different locations, with slightly different reqirements in each one.
• 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.
• Clarified certificate renewal and update. These represent a capability that was bolted onto the original protocol with (at best) vaguely-defined semantics, including a requirement by the server to guess whether a particular request was a renewal or not (updates were even more vaguely defined). In response to developer feedback that they either avoided renewal/update entirely because of this uncertainty or hardcoded in particular behaviour on a per-server basis, this specification explicitly identifies renewal and update requests as such, and provides proper semantics for both. Note that this is still a work in progress due to the lack of clarity of the original spec in this area, see some of the questions inline with the text.

Authors' Addresses