| RFC 8894 | SCEP | September 2020 |
| Gutmann | Informational | [Page] |
This document specifies the Simple Certificate Enrolment Protocol (SCEP), aPKI protocol that leverages existing technology by using Cryptographic MessageSyntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is theevolution of the enrolmentprotocol sponsored by Cisco Systems, which enjoys wide support in both clientand server implementations, as well as being relied upon by numerous otherindustry standards that work with certificates.¶
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 athttps://www.rfc-editor.org/info/rfc8894.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
X.509 certificates serve as the basis for several standardised securityprotocols such asTLS [RFC8446],S/MIME [RFC8551], andIKE/IPsec [RFC7296]. When an X.509certificate is issued, there typically is a need for a certificate managementprotocol to enable a PKI client to request or renew a certificate from aCertificate Authority (CA). This specification defines a protocol, the SimpleCertificate Enrolment Protocol (SCEP), for certificate management andcertificate and CRL queries.¶
The SCEP protocol supports the following general operations:¶
SCEP makes extensive use ofCMS [RFC5652]andPKCS #10 [RFC2986].¶
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 inSection 4.1.¶
This section provides an overview of the functionality of SCEP.¶
The entity types defined in SCEP are a client requesting a certificate and aCertificate Authority (CA) that issues the certificate. These are describedin the following sections.¶
A clientMUST have the following information locally configured:¶
A SCEP CA is the entity that signs client certificates. A CA may enforcepolicies and apply them to certificate requests, and it may reject a request forany reason.¶
Since the client is expected to perform signature verification and optionallyencryption using the CA certificate, the keyUsage extension in the CAcertificateMUST indicate that it is valid for digitalSignature andkeyEncipherment (if the key is to be used for en/decryption) alongside theusual CA usages of keyCertSign and/or cRLSign.¶
If the CA certificate(s) have not previously been acquired by the clientthrough some other means, the clientMUST retrieve them before any PKIoperation (Section 3) can be started. Since no public keyhas yet been exchanged between the client and the CA, the messages cannot besecured using CMS, and the CA certificate request and response data is insteadtransferred in the clear.¶
If an intermediate CA is in use, a certificates-only CMS SignedData messagewith a certificate chain consisting of all CA certificates is returned.Otherwise, the CA certificate itself is returned.¶
The CA certificateMAY be provided out of band to the client. Alternatively,the CA certificate fingerprintMAY be used to authenticate a CA certificatedistributed by the GetCACert response (Section 4.2) or viaHTTP certificate-store access [RFC4387]. Thefingerprint is created by calculating a SHA-256 hash over the whole CAcertificate. (For legacy reasons, a SHA-1 hash may be used by someimplementations.)¶
After the client gets the CA certificate, itSHOULD authenticate it in somemanner unless this is deemed unnecessary, for example, because the device isbeing provisioned inside a trusted environment. For example, the client could comparethe certificate's fingerprint with locally configured, out-of-band distributed, identifyinginformation, or by some equivalent means such as a direct comparison with alocally stored copy of the certificate.¶
Intermediate CA certificates, if any, are signed by a higher-level CA, so thereis no need to authenticate them against the out-of-band data. Sinceintermediate CA certificates are rolled over more frequently than long-livedtop-level CA certificates, clientsMUST verify intermediate-level CAcertificates before use during protocol exchanges in case the intermediate CAcertificate has expired or otherwise been invalidated.¶
When a CA certificate expires, certificates that have been signed by it may nolonger be regarded as valid. CA key rollover provides a mechanism by whichthe CA can distribute a new CA certificate that will be valid in the future oncethe current certificate has expired. This is done via the GetNextCACertmessage (Section 4.7).¶
As with every protocol that uses public-key cryptography, the associationbetween the public keys used in the protocol and the identities with whichthey are associated must be authenticated in a cryptographically securemanner. Communications between the client and the CA are secured using SCEPSecure Message Objects as explained inSection 3, whichspecifies how CMS is used to encrypt and sign the data. In order to performthe signing operation, the client uses an appropriate local certificate:¶
Note that although the above text describes several different types ofoperations, for historical reasons, most implementations always apply the firstone, even if an existing certificate already exists. For this reason, supportfor the first case is mandatory while support for the latter ones are optional(seeSection 2.9).¶
During the certificate-enrolment process, the clientMUST usethe selected certificate's key when signing the CMS envelope (seeSection 3). This certificate will be either theself-signed one matching the PKCS #10 request or the CA-issued one used toauthorise a renewal, and itMUST be included in the signedDatacertificates field (possibly as part of a full certificate chain). If the keybeing certified allows encryption, then the CA's CertResp will use the samecertificate's public key when encrypting the response.¶
Note that, in the case of renewal operations, this means that the request willbe signed and authenticated with the key in the previously issued certificaterather than the key in the PKCS #10 request, and the response may similarly bereturned encrypted with the key in the previously issued certificate. Thishas security implications; seeSection 7.6.¶
PKCS #10 [RFC2986] specifies aPKCS#9 [RFC2985] challengePassword attribute to be sent as part of the enrolmentrequest. When utilising the challengePassword, the CA distributes a sharedsecret to the client, which will be used to authenticate the request from theclient. It isRECOMMENDED that the challengePassword be aone-timeauthenticator value to limit the ability of an attacker who can capture theauthenticator from the client or CA and reuse it to request furthercertificates.¶
Inclusion of the challengePassword by the SCEP client isRECOMMENDED; however,its omission allows for unauthenticated authorisation of enrolment requests(which may, however, require manual approval of each certificate issue ifother security measures to control issue aren't in place; see below).Inclusion isOPTIONAL for renewal requests that are authenticated by beingsigned with an existing certificate. The CMS envelope protects the privacy ofthe challengePassword.¶
A client that is performing certificate renewal as perSection 2.5SHOULD omit the challengePassword butMAY sendthe originally distributed shared secret in the challengePassword attribute.The SCEP CAMAY authenticate the request using thechallengePassword in addition to the previously issued certificate that signsthe request. The SCEP CAMUST NOT attempt to authenticate aclient based on a self-signed certificate unless it has been verified throughout-of-band means such as a certificate fingerprint.¶
To perform the authorisation in manual mode, the client's request is placed inthe PENDING state until the CA operator authorises or rejects it. Manualauthorisation is used when the client has only a self-signed certificate thathasn't been previously authenticated by the CA and/or a challengePassword isnot available. The SCEP CAMAY either reject unauthorised requests or markthem for manual authorisation according to CA policy.¶
A client starts an enrolment transaction (Section 3.3.1) by creating acertificate request using PKCS #10 and sends the request to the CA envelopedusing CMS (Section 3).¶
If the CA supports certificate renewal and the CA policy permits, then a newcertificate with new validity dates can be issued, even though the old one isstill valid. To renew an existing certificate, the client uses the RenewalReqmessage (seeSection 3.3) and signs it with the existingclient certificate. The clientSHOULD use a new keypair when requesting a newcertificate butMAY request a new certificate using the old keypair.¶
If the CA returns a CertRep message (Section 3.3.2) with status setto PENDING, the client enters into polling mode by periodically sending aCertPoll message (Section 3.3.3) to the CA until the CA operatorcompletes the manual authentication (approving or denying the request). Thefrequency of the polling operation is a CA/client configuration issue and mayrange from seconds or minutes when the issue process is automatic but notinstantaneous, through to hours or days if the certificate-issue operationrequires manual approval.¶
If polling mode is being used, then the client will send a singlePKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or moreCertPoll messages (Section 3.3.3). The CA will, in return, send 0or more CertRep messages (Section 3.3.2) with status set to PENDINGin response to CertPolls, followed by a single CertRep message (Section 3.3.2) with status set to either SUCCESS orFAILURE.¶
The client state transitions during the SCEP process are indicated inFigure 1.¶
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. Sending aPKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING.¶
If the CA returns a CertRep message with pkiStatus set to SUCCESS, then thestate changes to CERT-ISSUED.¶
If the CA returns a CertRep message with pkiStatus set to FAILURE or there isno response, then the state reverts back to CERT-NONEXISTENT.¶
If the CA returns a CertRep message with pkiStatus set to PENDING, then theclient will keep polling by sending a CertPoll message until either a CertRepmessage 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 SERVERPKCSReq: PKI cert. enrolment message--------------------------------> CertRep: pkiStatus = SUCCESS Certificate attached <------------------------------Receive issued certificate.
Figure 3 shows a successful transaction in manual mode:¶
CLIENT CA SERVERPKCSReq: PKI cert. enrolment message--------------------------------> CertRep: pkiStatus = PENDING <------------------------------CertPoll: Polling message--------------------------------> CertRep: pkiStatus = PENDING <------------------------------................ <Manual identity authentication> ...............CertPoll: Polling message--------------------------------> CertRep: pkiStatus = SUCCESS Certificate attached <------------------------------Receive issued certificate.
A certificate query message is defined for clients to retrieve a copy of theirown certificate from the CA. It allows clients that do not store theircertificates locally to obtain a copy when needed. This functionality is notintended to provide a general-purpose certificate-access service, which may beachieved instead viaHTTP certificate-storeaccess [RFC4387] or Lightweight Directory Access Protocol (LDAP).¶
To retrieve a certificate from the CA, a client sends a request consisting ofthe certificate's issuer name and serial number. This assumes that the clienthas saved the issuer name and the serial number of the issued certificate fromthe previous enrolment transaction. The transaction to retrieve a certificateconsists of one GetCert (Section 3.3.4) message and one CertRep(Section 3.3.2) message, as shown inFigure 4.¶
CLIENT CA SERVERGetCert: PKI certificate query message-------------------------------> CertRep: pkiStatus = SUCCESS Certificate attached <-----------------------------Receive the certificate.
SCEP clientsMAY request a CRL via one of three methods:¶
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 oneCertRep PKI message, which contains only the CRL (no certificates) in adegenerate certificates-only CMS SignedData message(Section 3.4), as shown inFigure 5.¶
CLIENT CA SERVER GetCRL: PKI CRL query message----------------------------------> CertRep: CRL attached <-----------------------------Receive the CRL
SCEP does not specify a method to request certificate revocation. In order torevoke a certificate, the client must contact the CA using a non-SCEP-defined mechanism.¶
At a minimum, all SCEP implementations compliant with this specificationMUSTsupportGetCACaps (Section 3.5.1),GetCACert (Section 4.2),PKCSReq (Section 3.3.1) (and its associated response messages),communication of binary data viaHTTPPOST (Section 4.1), and theAES128-CBC [AES] andSHA-256 [SHA2] algorithms to securepkiMessages (Section 3.2).¶
For historical reasons, implementationsMAY support communications of binarydata viaHTTP GET (Section 4.1), and the triple DES-CBCand SHA-1 algorithms to securepkiMessages (Section 3.2).ImplementationsMUST NOT support the obsolete and/or insecure single DES andMD5 algorithms used in earlier versions of this specification, since theunsecured nature of GetCACaps means that an in-path attacker can triviallyroll back the encryption used to these insecure algorithms; seeSection 7.5.¶
CMS is a general enveloping mechanism that enables both signed and encryptedtransmission of arbitrary data. SCEP messages that require confidentialityuse two layers of CMS, as shown using ASN.1-like pseudocode inFigure 6. By applying both enveloping and signingtransformations, the SCEP message is protected both for the integrity of itsend-to-end transaction information and the confidentiality of its informationportion.¶
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 themessageData. CertRep messages will lack any signed content and consist onlyof a pkcsPKIEnvelope (Section 3.2.2).¶
The remainder of this document will refer only to "messageData", but it isunderstood to always be encapsulated in the pkcsPKIEnvelope (Section 3.2.2). The format of the data in the messageData isdefined by the messageType attribute (seeSection 3.2) of theSignedData. If there is no messageData to be transmitted, the entirepkcsPKIEnvelopeMUST be omitted.¶
Samples of SCEP messages are available through theJSCEP project [JSCEP] in the src/samples directory.¶
Creating a SCEP message consists of several stages. The content to beconveyed (in other words, the messageData) is first encrypted, and theencrypted content is then signed.¶
The form of encryption to be applied depends on the capabilities of therecipient's public key. If the key is encryption capable (for example, RSA),then the messageData is encrypted using the recipient's public key with theCMS KeyTransRecipientInfo mechanism. If the key is not encryption capable(for example, DSA or ECDSA), thenthe messageData is encrypted using thechallengePassword with the CMS PasswordRecipientInfo mechanism.¶
Once the messageData has been encrypted, it is signed with the sender's publickey. This completes the SCEP message, which is then sent to the recipient.¶
Note that some early implementations of this specification dealt with keysthat were not encryption capable by omitting the encryption stage, based on thetext inSection 3 that indicated that "the EnvelopedData isomitted". This alternative processing mechanismSHOULD NOT be used since itexposes in cleartext the challengePassword used to authorise the certificateissue.¶
The basic building block of all secured SCEP messages is the SCEP pkiMessage.It consists of a CMS SignedData content type. The following restrictionsapply:¶
At a minimum, all messagesMUST contain the following authenticatedAttributes:¶
If the message is a CertRep, itMUST also include the followingauthenticatedAttributes:¶
The following transaction attributes are encoded as authenticated attributesand carried in the SignerInfo for this SignedData.¶
| 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 |
| failInfoText | UTF8String | Descriptive text for the failInfo value |
| senderNonce | OCTET STRING | Random nonce as a 16-byte binary data string |
| recipientNonce | OCTET STRING | Random nonce as a 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)} |
| id-scep | OBJECT IDENTIFIER ::= {id-pkix 24} |
| id-scep-failInfoText | OBJECT IDENTIFIER ::= {id-scep 1} |
The attributes are detailed in the following sections.¶
A PKI operation is a transaction consisting of the messages exchanged betweena client and the CA. The transactionID is a text string provided by theclient when starting a transaction. The clientMUST use a unique string asthe transaction identifier, encoded as a PrintableString, whichMUST be usedfor all PKI messages exchanged for a given operation, such as a certificateissue.¶
Note that the transactionID must be unique, but not necessarily randomlygenerated. For example, it may be a value assigned by the CA to allow theclient to be identified by their transactionID, using a value such as theclient device's Extended Unique Identifier (EUI), Remote Terminal Unit (RTU) ID, or a similar uniqueidentifier. This can beuseful when the client doesn't have a preassigned Distinguished Name throughwhich the CA can identify their request -- for example, when enrollingSupervisory Control and Data Acquisition (SCADA) devices.¶
The messageType attribute specifies the type of operation performed by thetransaction. This attributeMUST be included in all PKI messages. Thefollowing 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. |
Message types not defined aboveMUST be treated as errors unless their usehas been negotiated throughGetCACaps (Section 3.5.1).¶
All response messagesMUST include transaction status information, which isdefined as a pkiStatus attribute:¶
| Value | Name | Description |
|---|---|---|
| 0 | SUCCESS | Request granted. |
| 2 | FAILURE | Request rejected. In this case, the failInfo attribute, as defined inSection 3.2.1.4,MUST also be present. |
| 3 | PENDING | Request pending for manual approval. |
PKI status values not defined aboveMUST be treated as errors unless theiruse has been negotiated throughGetCACaps (Section 3.5.1).¶
The failInfo attributeMUST 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. |
Failure reasons not defined aboveMUST be treated as errors unless their usehas been negotiated throughGetCACaps (Section 3.5.1).¶
The failInfoText is a free-form UTF-8 text string that provides furtherinformation in the case of pkiStatus = FAILURE. In particular, it may be usedto provide details on why a certificate request was not granted that go beyondwhat's provided by the near-universal failInfo = badRequest status. Sincethis is a free-form text string intended for interpretation by humans,implementationsSHOULD NOT assume that it has any type of machine-processablecontent.¶
The senderNonce and recipientNonce attributes are each a 16-byte random numbergenerated for each transaction. These are intended to prevent replay attacks.¶
When a sender sends a PKI message to a recipient, a fresh senderNonceMUST beincluded in the message. The recipientMUST copy the senderNonce into therecipientNonce of the reply as a proof of liveliness. The original senderMUST verify that the recipientNonce of the reply matches the senderNonce itsent in the request. If the nonce does not match, then the messageMUST berejected.¶
Note that since SCEP exchanges consist of a single request followed by asingle 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 thesame nonce in its reply. In effect, there's just a single nonce, identified assenderNonce in the client's request and recipientNonce in the CA's reply.¶
The information portion of a SCEP message is carried inside an EnvelopedDatacontent type, as defined in CMS, with the following restrictions:¶
All of the messages in this section are pkiMessages (Section 3.2), where the type of the messageMUST be specified in the"messageType" authenticated Attribute. Each section defines a valid messagetype, the corresponding messageData formats, and mandatory authenticatedattributes for that type.¶
The messageData for this type consists of a PKCS #10 Certificate Request. Thecertificate requestMUST contain at least the following items:¶
In addition, the message must contain the authenticatedAttributes specified inSection 3.2.1.¶
The messageData for this type consists of a degenerate certificates-only CMSSignedData message (Section 3.4). The exact content requiredfor the reply depends on the type of request that this message is a responseto. The request types are detailed in Sections3.3.2.1 and4. Inaddition, the message must contain theauthenticatedAttributes specified inSection 3.2.1.¶
Earlier draft versions of this specification required that this message include asenderNonce alongside the recipientNonce, which was to be used to chain tosubsequent polling operations. However, if a single message was lost duringthe potentially extended interval over which polling could take place (seeSection 5 for an example of this), then if theimplementation were to enforce this requirement, the overall transaction wouldfail, even though nothing had actually gone wrong. Because of this issue,implementations mostly ignored the requirement to either carry this nonce over tosubsequent polling messages or verify its presence. More recent versionsof the specification no longer require the chaining of nonces across pollingoperations.¶
When the pkiStatus attribute is set to SUCCESS, the messageData for thismessage consists of a degenerate certificates-only CMS SignedData message(Section 3.4). The content of this degeneratecertificates-only SignedData message depends on what the original request was, asoutlined inTable 6.¶
| Request-type | Reply-contents |
|---|---|
| PKCSReq | The replyMUST contain at least the issued certificate in the certificates field of the SignedData. The replyMAY contain additional certificates, but the issued certificateMUST be the leaf certificate. |
| RenewalReq | Same as PKCSReq |
| CertPoll | Same as PKCSReq |
| GetCert | The replyMUST contain at least the requested certificate in the certificates field of the SignedData. The replyMAY contain additional certificates, but the requested certificateMUST be the leaf certificate. |
| GetCRL | The replyMUST contain the CRL in the crls field of the SignedData. |
When the pkiStatus attribute is set to FAILURE, the replyMUST also contain afailInfo (Section 3.2.1.4) attribute set to the appropriate errorcondition describing the failure. The replyMAY also contain a failInfoTextattribute providing extended details on why the operation failed, typically toexpand on the catchall failInfo = badRequest status. The pkcsPKIEnvelope(Section 3.2.2)MUST be omitted.¶
When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (Section 3.2.2)MUST be omitted.¶
This message is used for certificate polling. For unknown reasons, it wasreferred 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 intendedissuerName of the certificate that's being requested). The subject is set tothe subjectName used when requesting the certificate.¶
Note that both of these fields are redundant; the CA is identified by therecipientInfo in the pkcsPKIEnvelope (or in most cases, simply by the serverthat the message is being sent to), and the client/transaction being polled isidentified by the transactionID. Both of these fields can be processed by theCA without going through the cryptographically expensive process of unwrappingand processing the issuerAndSubject. For this reason, implementationsSHOULDassume that the polling operation will be controlled by the recipientInfo andtransactionID rather than the contents of the messageData. In addition, themessage must contain the authenticatedAttributes specified inSection 3.2.1.¶
The messageData for these types consist of an IssuerAndSerialNumber, as definedin CMS, that uniquely identifies the certificate being requested, either thecertificate itself for GetCert or its revocation status via a CRL for GetCRL.In addition, the message must contain the authenticatedAttributes specifiedinSection 3.2.1.¶
These message types, while included here for completeness, apply unnecessarycryptography and messaging overhead to the simple task of transferring acertificate or CRL (seeSection 7.8).ImplementationsSHOULD preferHTTP certificate-store access [RFC4387] or LDAPover the use of these messages.¶
CMS includes a degenerate case of the SignedData content type in which thereare no signers. The use of such a degenerate case is to disseminatecertificates and CRLs. For SCEP, the content field of the ContentInfo value ofa degenerate certificates-only SignedDataMUST be omitted. When carryingcertificates, the certificates are included in the certificates field of theSignedData. When carrying a CRL, the CRL is included in the crls field ofthe SignedData.¶
In order to provide support for future enhancements to the protocol, CAsMUSTimplement the GetCACaps message to allow clients to query which functionalityis available from the CA.¶
This message requests capabilities from a CA, with the format as described inSection 4.1:¶
"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF¶
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):¶
| Keyword | Description |
|---|---|
| AES | CA supports the AES128-CBC encryption algorithm. |
| DES3 | CA supports the triple DES-CBC encryption algorithm. |
| GetNextCACert | CA supports the GetNextCACert message. |
| POSTPKIOperation | CA supports PKIOPeration messages 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. |
| SCEPStandard | CA supports all mandatory-to-implement sections of the SCEP standard. This keyword implies "AES", "POSTPKIOperation", and "SHA-256", as well as the provisions ofSection 2.9. |
Table 7 lists all of the keywords that are defined in thisspecification. A CAMAY provide additional keywords advertising furthercapabilities and functionality. A clientMUST be able to accept and ignoreany unknown keywords that might be sent by a CA.¶
The CAMUST use the text case specified here, but clientsSHOULD ignore the text case when processing this message. ClientsMUST accept the standardHTTP-style text delimited by <CR><LF> as well as thetext delimited by <LF> specified in an earlier draft version of thisspecification.¶
The clientSHOULD use SHA-256 in preference to SHA-1 hashing and AES128-CBC inpreference to triple DES-CBC if they are supported by the CA. Although theCMS format allows any form of AES and SHA-2 to be specified, in the interestsof interoperability the de facto universal standards of AES128-CBC and SHA-256SHOULD be used.¶
Announcing some of these capabilities individually is redundant, since they'rerequired as mandatory-to-implement functionality (seeSection 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 implementationsthat would otherwise default to obsolete, insecure algorithms and mechanisms.¶
If the CA supports none of the above capabilities, itSHOULD return an emptymessage. A CAMAY simply return an HTTP error. A client that receives anempty message or an HTTP errorSHOULD interpret the response as if none of thecapabilities listed are supported by the CA.¶
Note that at least one widely deployed server implementation supports severalof the above operations but doesn't support the GetCACaps message to indicatethat it supports them, and it will close the connection if sent a GetCACapsmessage. This means that the equivalent of GetCACaps must be performedthrough server fingerprinting, which can be done using the ID string"Microsoft-IIS". Newer versions of the same server, if sent a SCEP requestusing AES and SHA-2, will respond with an invalid response that can't bedecrypted, requiring the use of 3DES and SHA-1 in order to obtain a responsethat can be processed, even if AES and/or SHA-2 are allegedly supported. Inaddition, the server will generate CA certificates that only have one, but notboth, of the keyEncipherment and digitalSignature keyUsage flags set,requiring that the client ignore the keyUsage flags in order to use thecertificates for SCEP.¶
The Content-type of the replySHOULD be "text/plain". ClientsSHOULD ignorethe Content-type, as older implementations of SCEP may send variousContent-types.¶
Example:¶
GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1¶
might return:¶
AESGetNextCACertPOSTPKIOperationSCEPStandardSHA-256¶
This means that the CA supports modern crypto algorithms, and the GetNextCACertmessage allows PKIOperation messages (PKCSReq/RenewalReq, GetCert, CertPoll,...) to be sent using HTTP POST and is compliant with the final version ofthe SCEP standard.¶
This section describes the SCEP Transactions and theirHTTP [RFC7230] transport mechanism.¶
Note that SCEP doesn't follow best current practices on usage of HTTP. Inparticular, it recommends ignoring some media types and hard-codes specific URIpaths. Guidance on the appropriate application of HTTP in these circumstancesmay be found in[HTTP].¶
SCEP uses the HTTP POST and GET methods[RFC7230] toexchange information with the CA. The following defines the ABNF syntax ofHTTP POST and GET methods sent from a client to a CA:¶
POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION SP HTTP-version CRLFGETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION "&message=" MESSAGE SP HTTP-version CRLF¶
where:¶
The CA will typically ignore SCEPPATH, since it's unlikely to be issuingcertificates via a web server. ClientsSHOULD set SCEPPATH to the fixedstring "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA.The CASHOULD ignore the SCEPPATH unless its precise format is critical to theCA's operation.¶
Early SCEP drafts performed all communications via GET messages, includingnon-idempotent ones that should have been sent via POST messages; see[HTTP] for details. This has caused problems because ofthe way that the (supposedly) idempotent GET interacts with caches andproxies, and because the extremely large GET requests created by encoding CMSmessages may be truncated in transit. These issues are typically not visiblewhen testing on a LAN, but crop up during deployment over WANs. If the remoteCA supports POST, the CMS-encoded SCEP messagesMUST be sent via HTTP POSTinstead of HTTP GET. This applies to any SCEP message except GetCACert,GetNextCACert, and GetCACaps and avoids the need for base64 and URL encodingthat's required for GET messaging. The client can verify that the CA supportsSCEP messages via POST by looking for the "SCEPStandard" or "POSTPKIOperation"capability (seeSection 3.5.2).¶
If a client or CA uses HTTP GET and encounters HTTP-related problems such asmessages being truncated, seeing errors such as HTTP 414 ("Request-URI toolong"), or simply having the message not sent/received at all when standardrequests to the server (for example, via a web browser) work, then this is asymptom of the problematic use of HTTP GET. The solution to this problem isto update the implementation to use HTTP POST instead. In addition, when usingGET, it's recommended to test the implementation from as many different networklocations as possible to determine whether the use of GET will cause problemswith communications.¶
When using GET messages to communicate binary data, base64 encoding asspecified inSection 4 of [RFC4648]MUST be used. The base64-encoded data is distinct from"base64url" and may contain URI reservedcharacters; thus, itMUST be escaped as specified in[RFC3986] in addition to being base64 encoded.Finally, the encoded data is inserted intothe MESSAGE portion of the HTTP GET request.¶
To get the CA certificate(s), the client sends a GetCACert message to the CA.The OPERATIONMUST be set to "GetCACert". There is no request data associatedwith this message.¶
The response for GetCACert is different between the case where the CA directlycommunicates with the client during the enrolment and the case where anintermediate CA exists and the client communicates with this CA during theenrolment.¶
If the CA does not have any intermediate CA certificates, the responseconsists of a single X.509 CA certificate. The response will have aContent-Type of "application/x-x509-ca-cert".¶
"Content-Type: application/x-x509-ca-cert"<binary X.509>¶
If the CA has intermediate CA certificates, the response consists of adegenerate certificates-only CMS SignedData message (Section 3.4) containing the certificates, with the intermediate CAcertificate(s) as the leaf certificate(s). The response will have aContent-Type of "application/x-x509-ca-ra-cert". Note that this designationis used for historical reasons due to its use in older versions of thisspecification -- no special meaning should be attached to the label.¶
"Content-Type: application/x-x509-ca-ra-cert"<binary CMS>¶
A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform acertificate enrolment or renewal transaction. The OPERATIONMUST be set to"PKIOperation". Note that when used with HTTP POST, the only OPERATIONpossible is "PKIOperation", so many CAs don't check this value or even noticeits absence. When implemented using HTTP POST, the message is sent with aContent-Type of "application/x-pki-message" and might look as follows:¶
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1Content-Length: <length of data>Content-Type: application/x-pki-message<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¶
If the request is granted, a CertRep SUCCESS message(Section 3.3.2.1) is returned. If the request is rejected, aCertRep FAILURE message (Section 3.3.2.2) is returned. Ifthe CA is configured to manually authenticate the client, a CertRep PENDINGmessage (Section 3.3.2.3)MAY be returned. The CAMAY returna PENDING for other reasons.¶
The response will have a Content-Type of "application/x-pki-message".¶
"Content-Type: application/x-pki-message"<binary CertRep message>¶
When the client receives a CertRep message with pkiStatus set to PENDING, itwill enter the polling state by periodically sending CertPoll messages to theCA until either the request is granted and the certificate is sent back or therequest is rejected or some preconfigured time limit for polling or maximumnumber of polls is exceeded. The OPERATIONMUST be set to "PKIOperation".¶
CertPoll messages exchanged during the polling periodMUST carry the sametransactionID attribute as the previous PKCSReq/RenewalReq. A CA receiving aCertPoll for which it does not have a matching PKCSReq/RenewalReqMUST rejectthis request.¶
Since at this time the certificate has not been issued, the client can onlyuse its own subject name (which was contained in the original PKCS# 10 sentvia PKCSReq/RenewalReq) to identify the polled certificate request (but seethe note on identification during polling inSection 3.3.3). Intheory, there can be multiple outstanding requests from one client (forexample, if different keys and different key usages were used to requestmultiple certificates), so the transactionID must also be included todisambiguate between multiple requests. In practice, however, the clientSHOULD NOT have multiple requests outstanding at any one time, since this tends toconfuse some CAs.¶
The response messages for CertPoll are the same as inSection 4.3.1.¶
A client can query an issued certificate from the SCEP CA, as long as theclient knows the issuer name and the issuer-assigned certificate serialnumber.¶
This transaction consists of one GetCert (Section 3.3.4) messagesent to the CA by a client and one CertRep (Section 3.3.2) messagesent back from the CA. The OPERATIONMUST be set to "PKIOperation".¶
In this case, the CertRep from the CA is same as inSection 4.3.1, except that the CA will either grant therequest (SUCCESS) or reject it (FAILURE).¶
Clients can request a CRL from the SCEP CA, as described inSection 2.7. The OPERATIONMUST be set to "PKIOperation".¶
The CRL is sent back to the client in a CertRep (Section 3.3.2)message. The information portion of this message is a degeneratecertificates-only SignedData (Section 3.4) that contains onlythe most recent CRL in the crls field of the SignedData.¶
When a CA certificate is about to expire, clients need to retrieve the CA'snext CA certificate (i.e., the rollover certificate). This is done via theGetNextCACert message. The OPERATIONMUST be set to "GetNextCACert". Thereis no request data associated with this message.¶
The response consists of a SignedData CMS message, signed by the current CAsigning key. ClientsMUST validate the signature on the message beforetrusting 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"<binary CMS>¶
The content of the SignedData message is a degenerate certificates-onlySignedData message (Section 3.4) containing the new CAcertificate(s) to be used when the current CA certificate expires.¶
The following section gives several examples of client-to-CA transactions.Client actions are indicated in the left column, CA actions are indicated inthe right column, and the transactionID is given in parentheses. For ease ofreading, small integer values have been used; in practice, full transaction IDswould be used. The first transaction, for example, would read like this:¶
Client Sends PKCSReq message with transactionID 1 to the CA. The CA signsthe certificate and constructs a CertRep Message containing the signedcertificate with a transaction ID 1. The client receives the message andinstalls the certificate locally.¶
PKCSReq (1) ----------> CA issues certificate <---------- CertRep (1) SUCCESSClient installs certificate
PKCSReq (2) ----------> Cert request goes into queue <---------- CertRep (2) PENDINGCertPoll (2) ----------> Still pending <---------- CertRep (2) PENDINGCertPoll (2) ----------> CA issues certificate <---------- CertRep (2) SUCCESSClient installs certificate
GetNextCACert ----------> <---------- New CA certificatePKCSReq* ----------> CA issues certificate with new key <---------- CertRep SUCCESSClient stores certificatefor installation whenexisting certificate expires.
* Enveloped for the new CA certificate. The CA will use the envelope to determine which key to use to issue the client certificate.¶
In the case of polled transactions that aren't completed automatically, thereare two potential options for dealing with a transaction that's interrupteddue to network or software/hardware issues. The first is for the client topreserve its transaction state and resume the CertPoll polling when normalservice is restored. The second is for the client to begin a new transactionby sending a new PKCSReq/RenewalReq, rather than continuing the previousCertPoll. Both options have their own advantages and disadvantages.¶
The CertPoll continuation requires that the client maintain its transactionstate for the time when it resumes polling. This is relatively simple if theproblem is a brief network outage, but less simple when the problem is aclient crash and restart. In addition, the CA may treat a lost networkconnection as the end of a transaction, so that a new connection followed by aCertPoll 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 ifthe certificate was successfully issued but the client never received it,since the resumed transaction attempt will appear to be a request for aduplicate certificate (seeSection 7.4 for more on whythis is a problem). In this case, the CA may refuse the transaction orrequire manual intervention to remove/revoke the previous certificate beforethe client can request another one.¶
Since the new-transaction resume is more robust in the presence of errors anddoesn't require special-case handling by either the client or CA, clientsSHOULD use the new-transaction option in preference to the resumed-CertPolloption to recover from errors.¶
Resync Case 1: Client resyncs via new PKCSReq (recommended):¶
PKCSReq (3) ----------> Cert request goes into queue <---------- CertRep (3) PENDINGCertPoll (3) ----------> Still pending X-------- CertRep(3) PENDING(Network outage)(Client reconnects)PKCSReq (4) ----------> <---------- CertRep (4) PENDINGetc...
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) PENDINGCertPoll (5) ----------> Still pending X-------- CertRep(5) PENDING(Network outage)(Client reconnects)CertPoll (5) ----------> CA issues certificate <---------- CertRep (5) SUCCESSClient installs certificate
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) PENDINGCertPoll (6) ----------> Still pending <---------- CertRep (6) PENDINGCertPoll (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 certificatePKCSReq (8) ----------> CA issues new certificate <---------- CertRep (8) SUCCESSClient installs certificate
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) PENDINGCertPoll (9) ----------> Still pending <---------- CertRep (9) PENDINGCertPoll (9) ----------> CA issues certificate X-------- CertRep(9) SIGNED CERT(Network outage)(Client reconnects)CertPoll (9) ----------> Certificate already issued <---------- CertRep (9) SUCCESSClient installs certificate
As these examples indicate, resumption from an error via a resumed CertPoll istricky due to the state that needs to be held by both the client and/or theCA. A PKCSReq/RenewalReq resume is the easiest to implement, since it'sstateless and is identical for both polled and nonpolled transactions, whereasa CertPoll resume treats the two differently. (A nonpolled transaction isresumed with a PKCSReq/RenewalReq; a polled transaction is resumed with aCertPoll.) For this reason, error recoverySHOULD be handled via a new PKCSReqrather than a resumed CertPoll.¶
An object identifier for an arc to assign SCEP Attribute Identifiers has beenassigned in the "SMI Security for PKIX" registry (1.3.6.1.5.5.7). This objectidentifer, Simple Certificate Enrollment Protocol Attributes, is denoted asid-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 tothis 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, andSection 3.5 describes an "SCEP CA Capabilities"registry; these registries are maintained by IANA and define a number of suchcode-point identifiers. Entries in the registry are assigned accordingto 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 implementationsSHOULD use the "SCEP CA Capabilities"registry, SCEP is often employed in situations where this isn't possible. Inthis case, private-use CA capabilities may be specified using a unique prefixsuch as an organisation identifier or domain name under the control of theentity 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:¶
Note that these are grandfathered media types registered as perAppendix A of [RFC6838]. Templatesfor registrations are specified below.¶
The security goal of SCEP is that no adversary can subvert the publickey/identity binding from that intended. An adversary is any entity otherthan the client and the CA participating in the protocol.¶
This goal is met through the use of CMS and PKCS #10 encryption and digitalsignatures using authenticated public keys. The CA's public key isauthenticated 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 presharedsecret authentication.¶
Common key-management considerations such as keeping private keys trulyprivate and using adequate lengths for symmetric and asymmetric keys must befollowed in order to maintain the security of this protocol. This isespecially true for CA keys which, when compromised, compromise the securityof all relying parties.¶
A CA private key is generally meant for, and usually flagged as, beingusable for certificate (and CRL) signing exclusively rather than data signingor encryption. The SCEP protocol, however, uses the CA private key to both signand optionally encrypt CMS transport messages. This is generally consideredundesirable, as it widens the possibility of an implementation weakness andprovides an additional location where the private key must be used (and henceis slightly more vulnerable to exposure) and where a side-channel attack mightbe applied.¶
The security measures that should be applied to the challengePassword sharedsecret depend on the manner in which SCEP is employed. In the simplest case,with SCEP used to provision devices with certificates in the manufacturingfacility, the physical security of the facility may be enough to protect thecertificate issue process with no additional measures explicitly required. Ingeneral, though, the security of the issue process depends on the securityemployed around the use of the challengePassword shared secret. While it'snot possible to enumerate every situation in which SCEP may be utilised, thefollowing security measures should be considered.¶
SCEP provides no confirmation that the issued certificate was successfullyreceived and processed by the client. This means that if the CertRep messageis lost or can't be processed by the client, then the CA will consider thecertificate successfully issued while the client won't. If this situation isof concern, then the correct issuance of the certificate will need to beverified by out-of-band means, for example, through the client sending amessage signed by the newly issued certificate to the CA. This also providesthe proof of possession that's not present in the case of a renewal operation;seeSection 7.6.¶
The GetCACaps response is not authenticated by the CA. This allows anattacker to perform downgrade attacks on the cryptographic capabilities of theclient/CA exchange. In particular, if the server were to support MD5 andsingle DES, then an in-path attacker could trivially roll back the encryptionto use these insecure algorithms. By taking advantage of the presence oflarge amounts of static known plaintext in the SCEP messages, as of 2017, a DESrainbow table attack can recover most encryption keys in under a minute, andMD5 chosen-prefix collisions can be calculated for a few tens of cents ofcomputing time using tools like HashClash. It is for this reason that thisspecification makes single DES and MD5 aMUST NOT feature. Note that allknown 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 areason to fall all the way back to single DES and MD5.¶
One simple countermeasure to a GetCACaps downgrade attack is for clients thatare operating in an environment where on-path attacks are possible and thatexpect the "SCEPStandard" capability to be indicated by the CA but don't seeit in the GetCACaps response to treat its absence as a security issue, andeither discontinue the exchange or continue as if "SCEPStandard" had beenreturned. This requires a certain trade-off between compatibility with oldservers and security against active attacks.¶
Renewal operations (but not standard certificate-issue operations) areprocessed via a previously issued certificate and its associated private key,not the key in the PKCS #10 request. This means that a client no longerdemonstrates proof of possession (PoP) of the private key corresponding to thepublic key in the PKCS #10 request. It is therefore possible for a client torecertify an existing key used by a third party, so that two or morecertificates exist for the same key. By switching out the certificate in asignature, an attacker can appear to have a piece of data signed by theircertificate rather than the original signer's certificate. This, and other,attacks are described inS/MIME ESS [RFC2634].¶
Avoiding these types of attacks requires situation-specific measures. Forexample, CMS/SMIME implementations may use the ESSCertID attribute fromS/MIME ESS [RFC2634] or its successor,S/MIMEESSv2 [RFC5035], to unambiguously identify the signing certificate. However, sinceother mechanisms and protocols that the certificates will be used withtypically don't defend against this problem, it's unclear whether this is anactual issue with SCEP.¶
SCEP messages are signed with certificates that may contain identifyinginformation. If these are sent over the public Internet and real identityinformation (rather than placeholder values or arbitrary device IDs) isincluded in the signing certificate data, an attacker may be able to monitorthe identities of the entities submitting the certificate requests. If thisis an issue, then[RFC7258] should be consulted for guidance.¶
Some of the SCEP exchanges use unnecessary signing and encryption operations.In particular, the GetCert and GetCRL exchanges are encrypted and signed inboth directions. The information requested is public, and thus encrypting therequests is of questionable value. In addition, CRLs and certificates sent inresponses are already signed by the CA and can be verified by the recipientwithout requiring additional signing and encryption. More lightweight meansof retrieving certificates and CRLs such asHTTPcertificate-store access [RFC4387] and LDAP are recommended for this reason.¶
The majority of the large number of devices that use SCEP today default toSHA-1, with many supporting only that hash algorithm with no ability toupgrade to a newer one. SHA-1 is no longer regarded as secure in allsituations, but as used in SCEP, it's still safe. There are three reasons forthis. The first is that attacking SCEP would require creating a fully generalSHA-1 collision in close to real time alongside breaking AES (morespecifically, it would require creating a fully general SHA-1 collision forthe 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 encrypteddata), which won't be feasible for a long time.¶
The second reason is that the signature over the message -- in other words, theSHA-1 hash that isn't protected by encryption -- doesn't serve any criticalcryptographic purpose: The PKCS #10 data itself is authenticated through itsown signature, protected by encryption, and the overall request is authorisedby the (encrypted) shared secret. The sole exception to this will be thesmall number of implementations that support the Renewal operation, which maybe authorised purely through a signature, but presumably any implementationrecent enough to support Renewal also supports SHA-2. Any legacyimplementation that supports the historic core SCEP protocol would not beaffected.¶
The third reason is that SCEP uses the same key for encryption and signing, sothat even if an attacker were able to capture an outgoing renewal request thatdidn't include a shared secret (in other words, one that was only authorisedthrough a signature), break the AES encryption, forge the SHA-1 hash in realtime, and forward the forged request to the CA, they couldn't decrypt thereturned certificate, which is protected with the same key that was used togenerate the signature. WhileSection 7.8 pointsout that SCEP uses unnecessary cryptography in places, the additional level ofsecurity provided by the extra crypto makes it immune to any issues withSHA-1.¶
This doesn't mean that SCEP implementations should continue to use SHA-1 inperpetuity, merely that there's no need for a panicked switch to SHA-2.¶
SCEP is an encrypted, authenticated certificate enrollment protocol that usesHTTP as a simple transport mechanism. Since SCEP messages are alreadycryptographically secured, it does not require transport layer security. WhereHTTPS is elected, a performance hit may result from the TLS overhead,operational problems may result due to the more complex configuration, andpotential security vulnerability may result due to the addition of an entireTLS protocol stack alongside the basic SCEP protocol.¶
In particular, experience has shown that the issue of configuringcertificates, CAs, and trust for both TLS and SCEP often leads tointeroperability problems because different certificates and trust models areused in each. Use of HTTPS to authenticate the server does not enableomission of the ChallengePassword or similar authenticator in the SCEP messageon the assumption that using HTTPS instead of HTTP will somehow make thisinsecure usage secure again. HTTPS is not soy sauce for security and isunnecessary for SCEP, which uses cryptographically secured messages and doesnot require transport layer security.¶
This specification has spent over twenty years in the draft stage. Itsoriginal goal, provisioning IPsec routers with certificates, has long sincechanged to general device/embedded system/IoT use. To fit this role, extrafeatures were bolted on in a haphazard manner through the addition of agrowing list of appendices and by inserting additional, often conflicting,paragraphs in various locations in the body text. Since existing featureswere never updated as newer ones were added, the specification accumulatedlarge amounts of historical baggage over time. If OpenPGP was described as "amuseum of 1990s crypto", then the SCEP document was its graveyard.¶
About five years ago, the specification, which even at that point had seen onlysporadic reposts of the existing document, was more or less abandoned by itsoriginal sponsors. Due to its widespread use in large segments of theindustry, the specification was rebooted in 2015, cleaning up fifteen years'worth of accumulated cruft, fixing errors, clarifying ambiguities, andbringing the algorithms and standards used into the current century (prior tothe update, the de facto lowest-common-denominator algorithms used forinteroperability were the insecure forty-year-old single DES and broken MD5hash algorithms).¶
Note that although the text of the current specification has changedsignificantly due to the consolidation of features and appendices into themain document, the protocol that it describes is identical on the wire to theoriginal (with the unavoidable exception of the switch from single DES and MD5to AES and SHA-2). The only two changes introduced, the "SCEPStandard"indicator in GetCACaps and the failInfoText attribute, are both optionalvalues 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:¶
The editor would like to thank all of the previous editors, authors, andcontributors for their work maintaining thedocument over the years:Cheryl Madson,Xiaoyi Liu,David McGrew,David Cooper,Andy Nourse,Max Pritikin,Jan Vilhuber, and others. The IETF reviewers providedmuch useful feedback thathelped improve the document, and in particular spotted a number of things thatwere present in SCEP through established practice rather than by beingexplicitly described in the text. Numerous other people have contributedduring the long life cycle of the document, and all deserve thanks. In addition,several PKCS #7 / CMS libraries contributed to interoperability by doing theright thing despite what earlier SCEP documents required.¶
The authors of earlier draft versions of this document would like to thankPeter William of ValiCert, Inc. (formerly of VeriSign, Inc.),Alex Deacon ofVeriSign, Inc., andChristopher Welles of IRE, Inc. for their contributions toearly versions of this protocol and this document.¶