< draft-gutmann-scep-10.txt   draft-gutmann-scep-16.txt >
Network Working Group P. Gutmann Network Working Group P. Gutmann
Internet-Draft University of Auckland Internet-Draft University of Auckland
Intended status: Informational March 1, 2018 Intended status: Informational March 27, 2020
Expires: September 2, 2018 Expires: September 28, 2020
Simple Certificate Enrolment Protocol Simple Certificate Enrolment Protocol
draft-gutmann-scep-10 draft-gutmann-scep-16
Abstract Abstract
This document specifies the Simple Certificate Enrolment Protocol This document specifies the Simple Certificate Enrolment Protocol
(SCEP), a PKI protocol that leverages existing technology by using (SCEP), a PKI protocol that leverages existing technology by using
CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the
evolution of the enrolment protocol sponsored by Cisco Systems, which evolution of the enrolment protocol sponsored by Cisco Systems, which
enjoys wide support in both client and server implementations, as enjoys wide support in both client and server implementations, as
well as being relied upon by numerous other industry standards that well as being relied upon by numerous other industry standards that
work with certificates. work with certificates.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2018. This Internet-Draft will expire on September 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2. SCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Client . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 5 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 5
2.2. CA Certificate Distribution . . . . . . . . . . . . . . . 5 2.2. CA Certificate Distribution . . . . . . . . . . . . . . . 5
2.3. Client authentication . . . . . . . . . . . . . . . . . . 6 2.3. Client authentication . . . . . . . . . . . . . . . . . . 6
2.4. Enrolment authorization . . . . . . . . . . . . . . . . . 7 2.4. Enrolment authorisation . . . . . . . . . . . . . . . . . 7
2.5. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 8 2.5. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 8
2.5.1. Client State Transitions . . . . . . . . . . . . . . 8 2.5.1. Client State Transitions . . . . . . . . . . . . . . 8
2.6. Certificate Access . . . . . . . . . . . . . . . . . . . 10 2.6. Certificate Access . . . . . . . . . . . . . . . . . . . 10
2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 11 2.7. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 11
2.8. Certificate Revocation . . . . . . . . . . . . . . . . . 11 2.8. Certificate Revocation . . . . . . . . . . . . . . . . . 11
2.9. Mandatory-to-Implement Functionality . . . . . . . . . . 11 2.9. Mandatory-to-Implement Functionality . . . . . . . . . . 11
3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 12 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 12
3.1. SCEP Message Object Processing . . . . . . . . . . . . . 14 3.1. SCEP Message Object Processing . . . . . . . . . . . . . 14
3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14 3.2. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 14 3.2.1. Signed Transaction Attributes . . . . . . . . . . . . 14
skipping to change at page 2, line 51 skipping to change at page 2, line 51
3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 17 3.2.1.2. messageType . . . . . . . . . . . . . . . . . . . 17
3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 17 3.2.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 17
3.2.1.4. failInfo and failInfoText . . . . . . . . . . . . 17 3.2.1.4. failInfo and failInfoText . . . . . . . . . . . . 17
3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 18 3.2.1.5. senderNonce and recipientNonce . . . . . . . . . 18
3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 18 3.2.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . 18
3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 19 3.3. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 19
3.3.1. PKCSReq/RenewalReq . . . . . . . . . . . . . . . . . 19 3.3.1. PKCSReq/RenewalReq . . . . . . . . . . . . . . . . . 19
3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 20 3.3.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 20
3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 20 3.3.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 20
3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 21 3.3.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 20
3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 21 3.3.3. CertPoll (GetCertInitial) . . . . . . . . . . . . . . 21
3.3.4. GetCert and GetCRL . . . . . . . . . . . . . . . . . 22 3.3.4. GetCert and GetCRL . . . . . . . . . . . . . . . . . 21
3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 22 3.4. Degenerate certificates-only CMS Signed-Data . . . . . . 22
3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 22 3.5. CA Capabilities . . . . . . . . . . . . . . . . . . . . . 22
3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 22 3.5.1. GetCACaps HTTP Message Format . . . . . . . . . . . . 22
3.5.2. CA Capabilities Response Format . . . . . . . . . . . 23 3.5.2. CA Capabilities Response Format . . . . . . . . . . . 22
4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 25
4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 25 4.1. HTTP POST and GET Message Formats . . . . . . . . . . . . 25
4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26 4.2. Get CA Certificate . . . . . . . . . . . . . . . . . . . 26
4.2.1. Get CA Certificate Response Message Format . . . . . 26 4.2.1. Get CA Certificate Response Message Format . . . . . 27
4.2.1.1. CA Certificate Response Message Format . . . . . 27 4.2.1.1. CA Certificate Response Message Format . . . . . 27
4.2.1.2. CA Certificate Chain Response Message Format . . 27 4.2.1.2. CA Certificate Chain Response Message Format . . 27
4.3. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 27 4.3. Certificate Enrolment/Renewal . . . . . . . . . . . . . . 27
4.3.1. Certificate Enrolment/Renewal Response Message . . . 28 4.3.1. Certificate Enrolment/Renewal Response Message . . . 28
4.4. Poll for Client Initial Certificate . . . . . . . . . . . 28 4.4. Poll for Client Initial Certificate . . . . . . . . . . . 28
4.4.1. Polling Response Message Format . . . . . . . . . . . 29 4.4.1. Polling Response Message Format . . . . . . . . . . . 29
4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 29 4.5. Certificate Access . . . . . . . . . . . . . . . . . . . 29
4.5.1. Certificate Access Response Message Format . . . . . 29 4.5.1. Certificate Access Response Message Format . . . . . 29
4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. CRL Access . . . . . . . . . . . . . . . . . . . . . . . 29
4.6.1. CRL Access Response Message Format . . . . . . . . . 29 4.6.1. CRL Access Response Message Format . . . . . . . . . 29
4.7. Get Next Certificate Authority Certificate . . . . . . . 29 4.7. Get Next Certificate Authority Certificate . . . . . . . 29
4.7.1. Get Next CA Response Message Format . . . . . . . . . 30 4.7.1. Get Next CA Response Message Format . . . . . . . . . 30
5. SCEP Transaction Examples . . . . . . . . . . . . . . . . . . 30 5. SCEP Transaction Examples . . . . . . . . . . . . . . . . . . 30
5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30 5.1. Successful Transactions . . . . . . . . . . . . . . . . . 30
5.2. Transactions with Errors . . . . . . . . . . . . . . . . 31 5.2. Transactions with Errors . . . . . . . . . . . . . . . . 31
6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7.1. Registration of application/x-x509-ca-cert media type . . 35
8.1. General Security . . . . . . . . . . . . . . . . . . . . 35 7.2. Registration of application/x-x509-ca-ra-cert media type 36
8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 35 7.3. Registration of application/x-x509-next-ca-cert media
8.3. Challenge Password . . . . . . . . . . . . . . . . . . . 35 type . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 35 7.4. Registration of application/x-pki-message media type . . 38
8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8.6. Lack of PoP in Renewal Requests . . . . . . . . . . . . . 36 8.1. General Security . . . . . . . . . . . . . . . . . . . . 39
8.7. Unnecessary cryptography . . . . . . . . . . . . . . . . 36 8.2. Use of the CA private key . . . . . . . . . . . . . . . . 40
8.8. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 36 8.3. ChallengePassword Shared Secret Value . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.4. Lack of Certificate Issue Confirmation . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.5. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 38 8.6. Lack of PoP in Renewal Requests . . . . . . . . . . . . . 42
Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 38 8.7. Traffic Monitoring . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . 42
8.9. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Background Notes . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
X.509 certificates serve as the basis for several standards-based X.509 certificates serve as the basis for several standardised
security protocols such as TLS [17], S/MIME [14], and IKE/IPsec [13]. security protocols such as TLS [23], S/MIME [20], and IKE/IPsec [19].
When an X.509 certificate is issued there typically is a need for a When an X.509 certificate is issued there typically is a need for a
certificate management protocol to enable a PKI client to request or certificate management protocol to enable a PKI client to request or
renew a certificate from a Certificate Authority (CA). renew a certificate from a Certificate Authority (CA). This
specification defines a protocol, Simple Certificate Enrolment
This specification defines a protocol, Simple Certificate Enrolment
Protocol (SCEP), for certificate management and certificate and CRL Protocol (SCEP), for certificate management and certificate and CRL
queries. While widely deployed (see the Background Notes queries.
(Appendix A) section for more on the history behind SCEP and the
nearly two decade-long progress of this standard), this protocol
omits some certificate management features, e.g. certificate
revocation transactions, which may enhance the security achieved in a
PKI. The IETF protocol suite currently includes two further
certificate management protocols with more comprehensive
functionality, Certificate Management Protocol (CMP) [10] and
Certificate Management over CMS (CMC) [9]. Environments that do not
require interoperability with SCEP implementations MAY consider using
the above-mentioned certificate management protocols, however anyone
considering this step should be aware that the high level of
complexity of these two protocols has resulted in serious
interoperability problems and corresponding lack of industry support.
SCEP's simplicity, while being a drawback in terms of its slightly
restricted functionality, also makes deployment relatively
straightforward, so that it enjoys widespread support and ready
interoperability across a range of platforms. While implementers are
encouraged to investigate one of the more comprehensive alternative
certificate management protocols in addition to the protocol defined
in this specification, anyone wishing to deploy them should proceed
with caution, and consider support and interoperability issues before
committing to their use.
The SCEP protocol supports the following general operations: The SCEP protocol supports the following general operations:
o CA public key distribution. o CA public key distribution.
o Certificate enrolment and issue. o Certificate enrolment and issue.
o Certificate renewal. o Certificate renewal.
o Certificate query. o Certificate query.
o CRL query. o CRL query.
SCEP makes extensive use of CMS [3] and PKCS #10 [6]. SCEP makes extensive use of CMS [10] and PKCS #10 [13].
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [1]. "OPTIONAL" in this document are to be interpreted as described in [1]
and [5] 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 [6] for defining formal syntax of commands. Non-
terminals not defined in [6] are defined in Section 4.1.
2. SCEP Overview 2. SCEP Overview
This section provides a high level overview of the functionality of This section provides an overview of the functionality of SCEP.
SCEP.
2.1. SCEP Entities 2.1. SCEP Entities
The entity types defined in SCEP are a client requesting a The entity types defined in SCEP are a client requesting a
certificate and a Certificate Authority (CA) that issues the certificate and a Certificate Authority (CA) that issues the
certificate. These are described in the following sections. certificate. These are described in the following sections.
2.1.1. Client 2.1.1. Client
A client MUST have the following information locally configured: A client MUST have the following information locally configured:
1. The CA fully qualified domain name or IP address. 1. The CA's fully qualified domain name or IP address.
2. The CA HTTP CGI script path (this usually has a default value,
see Section 4.1). 2. Any identification and/or authorisation information required by
the CA before a certificate will be issued, as described in
Section 3.3.1.
3. The identifying information that is used for authentication of 3. The identifying information that is used for authentication of
the CA in Section 4.2.1, typically a certificate fingerprint. the CA in Section 4.2.1, typically a certificate fingerprint.
2.1.2. Certificate Authority 2.1.2. Certificate Authority
A SCEP CA is the entity that signs client certificates. A CA MAY A SCEP CA is the entity that signs client certificates. A CA may
enforce any arbitrary policies and apply them to certificate enforce policies and apply them to certificate requests, and may
requests, and MAY reject a request for any reason. reject a request for any reason.
Since the client is expected to perform signature verification and Since the client is expected to perform signature verification and
optionally encryption using the CA certificate, the keyUsage optionally encryption using the CA certificate, the keyUsage
extension in the CA certificate MUST indicate that it is valid for extension in the CA certificate MUST indicate that it is valid for
digitalSignature and keyEncipherment (if available) alongside the digitalSignature and keyEncipherment (if the key is to be used for
usual CA usages of keyCertSign and/or cRLSign. en/decryption) alongside the usual CA usages of keyCertSign and/or
cRLSign.
2.2. CA Certificate Distribution 2.2. CA Certificate Distribution
If the CA certificate(s) have not previously been acquired by the If the CA certificate(s) have not previously been acquired by the
client through some other means, the client MUST retrieve them before client through some other means, the client MUST retrieve them before
any PKI operation (Section 3) can be started. Since no public key any PKI operation (Section 3) can be started. Since no public key
has yet been exchanged between the client and the CA, the messages has yet been exchanged between the client and the CA, the messages
cannot be secured using CMS, and the data is instead transferred in cannot be secured using CMS, and the CA certificate request and
the clear. response data is instead transferred in the clear.
If an intermediate CA is in use, a certificates-only CMS Signed-Data If an intermediate CA is in use, a certificates-only CMS Signed-Data
message with a certificate chain consisting of all CA certificates is message with a certificate chain consisting of all CA certificates is
returned. Otherwise the CA certificate itself is returned. returned. Otherwise the CA certificate itself is returned.
The CA certificate MAY be provided out-of-band to the client. The CA certificate MAY be provided out-of-band to the client.
Alternatively, the CA certificate fingerprint MAY be used to Alternatively, the CA certificate fingerprint MAY be used to
authenticate a CA Certificate distributed by the GetCACert response authenticate a CA Certificate distributed by the GetCACert response
(Section 4.2) or via HTTP certificate-store access [11]. The (Section 4.2) or via HTTP certificate-store access [17]. The
fingerprint is created by calculating a SHA-256 hash over the whole fingerprint is created by calculating a SHA-256 hash over the whole
CA certificate (for legacy reasons, a SHA-1 hash may be used by some CA certificate (for legacy reasons, a SHA-1 hash may be used by some
implementations). implementations).
After the client gets the CA certificate, it SHOULD authenticate the After the client gets the CA certificate, it SHOULD authenticate it
certificate by comparing its fingerprint with the locally configured, in some manner unless this is deemed unnecessary, for example because
the device is being provisioned inside a trusted environment. For
example it could compare its fingerprint with locally configured,
out-of-band distributed, identifying information, or by some out-of-band distributed, identifying information, or by some
equivalent means such as a direct comparison with a locally-stored equivalent means such as a direct comparison with a locally-stored
copy of the certificate. Intermediate CA certificates, if any, are copy of the certificate.
signed by a higher-level CA so there is no need to authenticate them
against the out-of-band data. Clients SHOULD verify intermediate- Intermediate CA certificates, if any, are signed by a higher-level CA
level CA certificate signatures using the issuing CA's certificate so there is no need to authenticate them against the out-of-band
before use during protocol exchanges. data. Since intermediate CA certificates are rolled over more
frequently than long-lived top-level CA certificates, clients MUST
verify intermediate-level CA certificates before use during protocol
exchanges in case the intermediate CA certificate has expired or
otherwise been invalidated.
When a CA certificate expires, certificates that have been signed by When a CA certificate expires, certificates that have been signed by
it may no longer be regarded as valid. CA key rollover provides a it may no longer be regarded as valid. CA key rollover provides a
mechanism by which the CA MAY distribute a new CA certificate which mechanism by which the CA can distribute a new CA certificate which
is valid in the future once the current certificate has expired. is valid in the future once the current certificate has expired.
This is done in the GetNextCACert message (section Section 4.7). This is done via the GetNextCACert message (section Section 4.7).
2.3. Client authentication 2.3. Client authentication
As with every protocol that uses public-key cryptography, the As with every protocol that uses public-key cryptography, the
association between the public keys used in the protocol and the association between the public keys used in the protocol and the
identities with which they are associated must be authenticated in a identities with which they are associated must be authenticated in a
cryptographically secure manner. The communications between the cryptographically secure manner. Communications between the client
client and the CA are secured using SCEP Secure Message Objects as and the CA are secured using SCEP Secure Message Objects as explained
explained in Section 3, which specifies how CMS is used to encrypt in Section 3, which specifies how CMS is used to encrypt and sign the
and sign the data. In order to perform the signing operation the data. In order to perform the signing operation the client uses an
client uses an appropriate local certificate: appropriate local certificate:
1. If the client does not have an appropriate existing certificate 1. If the client does not have an appropriate existing certificate
then a locally generated self-signed certificate MUST be used. then a locally generated self-signed certificate MUST be used.
The keyUsage extension in the certificate MUST indicate that it The keyUsage extension in the certificate MUST indicate that it
is valid for digitalSignature and keyEncipherment (if available). is valid for digitalSignature and keyEncipherment (if available).
The self-signed certificate SHOULD use the same subject name as The self-signed certificate SHOULD use the same subject name and
in the PKCS #10 request. In this case the messageType is PKCSReq key as in the PKCS #10 request. In this case the messageType is
(see Section 3.2.1.2). PKCSReq (see Section 3.2.1.2).
2. If the requesting system already has a certificate issued by the 2. If the client already has a certificate issued by the SCEP CA and
SCEP CA and the CA supports renewal (see Section 2.5), that the CA supports renewal (see Section 2.5), that certificate
certificate SHOULD be used. In this case the messageType is SHOULD be used. In this case the messageType is RenewalReq (see
RenewalReq (see Section 3.2.1.2). Section 3.2.1.2).
3. Alternatively, if the requesting system has no certificate issued 3. Alternatively, if the client has no certificate issued by the
by the SCEP CA but has credentials from an alternate CA then the SCEP CA but has credentials from an alternate CA then the
certificate issued by the alternate CA MAY be used in a renewal certificate issued by the alternate CA MAY be used in a renewal
request as described above. Policy settings on the SCEP CA will request as described above. The SCEP CA's policy will determine
determine if the request can be accepted or not. whether the request can be accepted or not.
Note that although the above text describes several different types Note that although the above text describes several different types
of operations, in practice most implementations always apply the of operations, for historical reasons most implementations always
first one even if an existing certificate already exists. For this apply the first one even if an existing certificate already exists.
reason support for the first case is mandatory while support for the For this reason support for the first case is mandatory while support
latter ones are optional (see Section 2.9). for the latter ones are optional (see Section 2.9).
During the certificate enrolment process, the client MUST use the During the certificate enrolment process, the client MUST use the
selected certificate's key when signing the CMS envelope (see selected certificate's key when signing the CMS envelope (see
Section 3). This certificate will be either the self-signed one Section 3). This certificate will be either the self-signed one
matching the PKCS #10 request or the CA-issued one used to authorise matching the PKCS #10 request or the CA-issued one used to authorise
a renewal, and MUST be included in the signedData certificates field a renewal, and MUST be included in the signedData certificates field
(possibly as part of a full certificate chain). If the key being (possibly as part of a full certificate chain). If the key being
certified allows encryption then the CA's CertResp will use the same certified allows encryption then the CA's CertResp will use the same
certificate's public key when encrypting the response. certificate's public key when encrypting the response.
Note that this means that, in the case of renewal operations, the Note that in the case of renewal operations this means that the
request is signed with, and the returned response may be encrypted request will be signed and authenticated with the key in the
with, the key in the previously-issued certificate used to previously-issued certificate rather than the key in the PKCS #10
authenticate the request, not the key in the PKCS #10 request. This request, and the response may similarly be returned encrypted with
has security implications, see Section 8.6. the key in the previously-issued certificate. This has security
implications, see Section 8.6.
2.4. Enrolment authorization 2.4. Enrolment authorisation
PKCS #10 [6] specifies a PKCS #9 [5] challengePassword attribute to PKCS #10 [13] specifies a PKCS #9 [12] challengePassword attribute to
be sent as part of the enrolment request. When utilizing the be sent as part of the enrolment request. When utilizing the
challengePassword, the CA distributes a shared secret to the client challengePassword, the CA distributes a shared secret to the client
which will uniquely associate the enrolment request with the client. which will be used to authenticate the request from the the client.
It is RECOMMENDED that the challengePassword be a one-time
authenticator value to limit the ability of an attacker who can
capture the authenticator from the client or CA to re-use it to
request further certificates.
Inclusion of the challengePassword by the SCEP client is OPTIONAL and Inclusion of the challengePassword by the SCEP client is RECOMMENDED,
allows for unauthenticated authorization of enrolment requests however its omission allows for unauthenticated authorisation of
(which, however, requires manual approval of each certificate issue, enrolment requests (which may, however, require manual approval of
see below), or for renewal requests that are authenticated by being each certificate issue if other security measures to control issue
signed with an existing certificate. The CMS envelope protects the aren't in place, see below). Inclusion is OPTIONAL for renewal
privacy of the challengePassword. requests that are authenticated by being signed with an existing
certificate. The CMS envelope protects the privacy of the
challengePassword.
A client that is performing certificate renewal as per Section 2.5 A client that is performing certificate renewal as per Section 2.5
SHOULD omit the challengePassword but MAY send the originally SHOULD omit the challengePassword but MAY send the originally
distributed password in the challengePassword attribute. The SCEP CA distributed shared secret in the challengePassword attribute. The
MAY use the challengePassword in addition to the previously issued SCEP CA MAY use the challengePassword in addition to the previously
certificate that signs the request to authenticate the request. The issued certificate that signs the request to authenticate the
SCEP CA MUST NOT attempt to authenticate a client based on a self- request. The SCEP CA MUST NOT attempt to authenticate a client based
signed certificate unless it has been verified through out-of-band on a self-signed certificate unless it has been verified through out-
means such as a certificate fingerprint. of-band means such as a certificate fingerprint.
To perform the authorization in manual mode the client's request is To perform the authorisation in manual mode the client's request is
placed in the PENDING state until the CA operator authorizes or placed in the PENDING state until the CA operator authorises or
rejects it. Manual authorization is used when the client has only a rejects it. Manual authorisation is used when the client has only a
self-signed certificate that hasn't been previously authenticated by self-signed certificate that hasn't been previously authenticated by
the CA and/or a challengePassword is not available. The SCEP CA MAY the CA and/or a challengePassword is not available. The SCEP CA MAY
either reject unauthorized requests or mark them for manual either reject unauthorised requests or mark them for manual
authorization according to CA policy. authorisation according to CA policy.
2.5. Certificate Enrolment/Renewal 2.5. Certificate Enrolment/Renewal
A client starts an enrolment transaction (Section 3.3.1) by creating A client starts an enrolment transaction (Section 3.3.1) by creating
a certificate request using PKCS #10 and sends it to the CA enveloped a certificate request using PKCS #10 and sends it to the CA enveloped
using CMS (Section 3). using CMS (Section 3).
If the CA supports certificate renewal and if the CA policy permits If the CA supports certificate renewal and if the CA policy permits
then a new certificate with new validity dates can be issued even then a new certificate with new validity dates can be issued even
though the old one is still valid. The CA MAY automatically revoke though the old one is still valid. To renew an existing certificate,
the old client certificate. To renew an existing certificate, the the client uses the RenewalReq message (see Section 3.3) and signs it
client uses the RenewalReq message (see Section 3.3) and signs it
with the existing client certificate. The client SHOULD use a new with the existing client certificate. The client SHOULD use a new
keypair when requesting a new certificate, but MAY request a new keypair when requesting a new certificate, but MAY request a new
certificate using the old keypair. certificate using the old keypair.
If the CA returns a CertRep message (Section 3.3.2) with status set If the CA returns a CertRep message (Section 3.3.2) with status set
to PENDING, the client enters into polling mode by periodically to PENDING, the client enters into polling mode by periodically
sending a CertPoll message (Section 3.3.3) to the CA until the CA sending a CertPoll message (Section 3.3.3) to the CA until the CA
operator completes the manual authentication (approving or denying operator completes the manual authentication (approving or denying
the request). the request). The frequency of the polling operation is a CA/client
configuration issue, and may range from seconds or minutes when the
issue process is automatic but not instantaneous, through to hours or
days if the certificate issue operation requires manual approval.
If polling mode is being used then the client will send a single If polling mode is being used then the client will send a single
PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more
CertPoll messages (Section 3.3.3). The CA will in return send 0 or CertPoll messages (Section 3.3.3). The CA will in return send 0 or
more CertRep messages (Section 3.3.2) with status set to PENDING in more CertRep messages (Section 3.3.2) with status set to PENDING in
response to CertPolls, followed by a single CertRep message response to CertPolls, followed by a single CertRep message
(Section 3.3.2) with status set to either SUCCESS or FAILURE. (Section 3.3.2) with status set to either SUCCESS or FAILURE.
2.5.1. Client State Transitions 2.5.1. Client State Transitions
skipping to change at page 10, line 29 skipping to change at page 10, line 29
Certificate attached Certificate attached
<------------------------------ <------------------------------
Receive issued certificate. Receive issued certificate.
2.6. Certificate Access 2.6. Certificate Access
A certificate query message is defined for clients to retrieve a copy A certificate query message is defined for clients to retrieve a copy
of their own certificate from the CA. It allows clients that do not of their own certificate from the CA. It allows clients that do not
store their certificates locally to obtain a copy when needed. This store their certificates locally to obtain a copy when needed. This
functionality is not intended to provide a general purpose functionality is not intended to provide a general purpose
certificate access service, which may be achieved via HTTP certificate access service, which may be instead be achieved via HTTP
certificate-store access [11] or LDAP. certificate-store access [17] or LDAP.
To query a certificate from the CA, a client sends a request To retrieve a certificate from the CA, a client sends a request
consisting of the certificate's issuer name and serial number. This consisting of the certificate's issuer name and serial number. This
assumes that the client has saved the issuer name and the serial assumes that the client has saved the issuer name and the serial
number of the issued certificate from the previous enrolment number of the issued certificate from the previous enrolment
transaction. The transaction to query a certificate consists of one transaction. The transaction to retrieve a certificate consists of
GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) one GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2)
message, as shown below. message, as shown below.
CLIENT CA SERVER CLIENT CA SERVER
GetCert: PKI certificate query message GetCert: PKI certificate query message
-------------------------------> CertRep: pkiStatus = SUCCESS -------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached Certificate attached
<----------------------------- <-----------------------------
Receive the certificate. Receive the certificate.
2.7. CRL Access 2.7. CRL Access
SCEP clients MAY request a CRL via one of three methods: SCEP clients MAY request a CRL via one of three methods:
1. If the CA supports CRL Distribution Points (CRLDPs) [7], then the 1. If the CA supports the CRL Distribution Points (CRLDPs) extension
CRL MAY be retrieved via the mechanism specified in the CRDLP. [14] in issued certificates, then the CRL MAY be retrieved via
2. If the CA supports HTTP certificate-store access [11], then the the mechanism specified in the CRDLP.
CRL MAY be retrieved via the AuthorityInfoAcces [7] location 2. If the CA supports HTTP certificate-store access [17], then the
CRL MAY be retrieved via the AuthorityInfoAcces [14] location
specified in the certificate. specified in the certificate.
3. Only if the CA does not support CRDLPs or HTTP access should a 3. Only if the CA does not support CRDLPs or HTTP access should a
CRL query be composed by creating a GetCRL message consisting of CRL query be composed by creating a GetCRL message consisting of
the issuer name and serial number from the certificate whose the issuer name and serial number from the certificate whose
revocation status is being queried. revocation status is being queried.
The CA SHOULD NOT support the GetCRL method because it does not scale
well due to the unnecessary cryptography (see Section 8.7) and it
requires the CA to be a high-availability service.
The message is sent to the SCEP CA in the same way as the other SCEP 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 requests. The transaction to retrieve a CRL consists of one GetCRL
PKI message and one CertRep PKI message, which contains only the CRL PKI message and one CertRep PKI message, which contains only the CRL
(no certificates) in a degenerate certificates-only CMS Signed-Data (no certificates) in a degenerate certificates-only CMS Signed-Data
message (Section 3.4), as shown below. message (Section 3.4), as shown below.
CLIENT CA SERVER CLIENT CA SERVER
GetCRL: PKI CRL query message GetCRL: PKI CRL query message
----------------------------------> ---------------------------------->
skipping to change at page 12, line 4 skipping to change at page 11, line 46
SCEP does not specify a method to request certificate revocation. In SCEP does not specify a method to request certificate revocation. In
order to revoke a certificate, the client must contact the CA using a order to revoke a certificate, the client must contact the CA using a
non-SCEP defined mechanism. non-SCEP defined mechanism.
2.9. Mandatory-to-Implement Functionality 2.9. Mandatory-to-Implement Functionality
At a minimum, all SCEP implementations compliant with this At a minimum, all SCEP implementations compliant with this
specification MUST support GetCACaps (Section 3.5.1), GetCACert specification MUST support GetCACaps (Section 3.5.1), GetCACert
(Section 4.2), PKCSReq (Section 3.3.1) (and its associated response (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response
messages), communication of binary data via HTTP POST (Section 4.1), messages), communication of binary data via HTTP POST (Section 4.1),
and the AES and SHA-256 algorithms to secure pkiMessages and the AES128-CBC [7] and SHA-256 [8] algorithms to secure
(Section 3.2). pkiMessages (Section 3.2).
For historical reasons implementations MAY support communications of For historical reasons implementations MAY support communications of
binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1 binary data via HTTP GET (Section 4.1), and the triple DES-CBC and
algorithms to secure pkiMessages (Section 3.2). Implementations MUST SHA-1 algorithms to secure pkiMessages (Section 3.2).
NOT support the obsolete and/or insecure single DES and MD5 Implementations MUST NOT support the obsolete and/or insecure single
algorithms used in earlier versions of this specification, since the DES and MD5 algorithms used in earlier versions of this
unsecured nature of GetCACaps means that an in-path attacker can specification, since the unsecured nature of GetCACaps means that an
trivially roll back the encryption used to these insecure algorithms, in-path attacker can trivially roll back the encryption used to these
see Section 8.5. insecure algorithms, see Section 8.5.
3. SCEP Secure Message Objects 3. SCEP Secure Message Objects
CMS is a general enveloping mechanism that enables both signed and CMS is a general enveloping mechanism that enables both signed and
encrypted transmission of arbitrary data. SCEP messages that require encrypted transmission of arbitrary data. SCEP messages that require
confidentiality use two layers of CMS, as shown in Figure 2. By confidentiality use two layers of CMS, as shown using ASN.1-like
applying both enveloping and signing transformations, the SCEP pseudocode in Figure 2. By applying both enveloping and signing
message is protected both for the integrity of its end-to-end transformations, the SCEP message is protected both for the integrity
transaction information and the confidentiality of its information of its end-to-end transaction information and the confidentiality of
portion. Some messages do not require enveloping, in which case the its information portion.
EnvelopedData in Figure 2 is omitted.
pkiMessage { pkiMessage {
contentType = signedData { pkcs-7 2 }, contentType = signedData { pkcs-7 2 },
content { content {
digestAlgorithms, digestAlgorithms,
encapsulatedContentInfo { encapsulatedContentInfo {
eContentType = data { pkcs-7 1 }, eContentType = data { pkcs-7 1 },
eContent { -- pkcsPKIEnvelope, optional eContent { -- pkcsPKIEnvelope, optional
contentType = envelopedData { pkcs-7 3 }, contentType = envelopedData { pkcs-7 3 },
content { content {
skipping to change at page 14, line 5 skipping to change at page 14, line 5
the messageData. CertRep messages will lack any signed content and the messageData. CertRep messages will lack any signed content and
consist only of a pkcsPKIEnvelope (Section 3.2.2). consist only of a pkcsPKIEnvelope (Section 3.2.2).
The remainder of this document will refer only to 'messageData', but The remainder of this document will refer only to 'messageData', but
it is understood to always be encapsulated in the pkcsPKIEnvelope it is understood to always be encapsulated in the pkcsPKIEnvelope
(Section 3.2.2). The format of the data in the messageData is (Section 3.2.2). The format of the data in the messageData is
defined by the messageType attribute (see Section 3.2) of the Signed- defined by the messageType attribute (see Section 3.2) of the Signed-
Data. If there is no messageData to be transmitted, the entire Data. If there is no messageData to be transmitted, the entire
pkcsPKIEnvelope MUST be omitted. pkcsPKIEnvelope MUST be omitted.
Samples of SCEP messages are available through the JSCEP project [12] Samples of SCEP messages are available through the JSCEP project [18]
in the src/samples directory. in the src/samples directory.
3.1. SCEP Message Object Processing 3.1. SCEP Message Object Processing
Creating a SCEP message consists of several stages. The content to Creating a SCEP message consists of several stages. The content to
be conveyed (in other words the messageData) is first encrypted, and be conveyed (in other words the messageData) is first encrypted, and
the encrypted content is then signed. the encrypted content is then signed.
The form of encryption to be applied depends on the capabilities of The form of encryption to be applied depends on the capabilities of
the recipient's public key. If the key is encryption-capable (for the recipient's public key. If the key is encryption-capable (for
example RSA) then the messageData is encrypted using the recipient's example RSA) then the messageData is encrypted using the recipient's
public key with the CMS KeyTransRecipientInfo mechanism. If the key public key with the CMS KeyTransRecipientInfo mechanism. If the key
is not encryption-capable (for example DSA or ECDSA) then the is not encryption-capable (for example DSA or ECDSA) then the
messageData is encrypted using the challengePassword with the CMS messageData is encrypted using the challengePassword with the CMS
PasswordRecipientInfo mechanism. PasswordRecipientInfo mechanism.
Once the messageData has been encrypted, it is signed with the Once the messageData has been encrypted, it is signed with the
sender's public key. This completes the SCEP message that is then sender's public key. This completes the SCEP message that is then
sent to the recipient. sent to the recipient.
Note that some earlier implementations of this specification dealt Note that some early implementations of this specification dealt with
with non-encryption-capable keys by omitting the encryption stage, non-encryption-capable keys by omitting the encryption stage, based
based on the text in Section 3 that indicated that "the EnvelopedData on the text in Section 3 that indicated that "the EnvelopedData is
is omitted". This alternative processing mechanism SHOULD NOT be omitted". This alternative processing mechanism SHOULD NOT be used
used since it exposes the challengePassword used to authorise the since it exposes in cleartext the challengePassword used to authorise
certificate issue. the certificate issue.
3.2. SCEP pkiMessage 3.2. SCEP pkiMessage
The basic building block of all secured SCEP messages is the SCEP The basic building block of all secured SCEP messages is the SCEP
pkiMessage. It consists of a CMS Signed-Data content type. The pkiMessage. It consists of a CMS Signed-Data content type. The
following restrictions apply: following restrictions apply:
o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 o The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7
1}). 1}).
o The signed content, if present (FAILURE and PENDING CertRep o The signed content, if present (FAILURE and PENDING CertRep
skipping to change at page 15, line 6 skipping to change at page 15, line 6
(Section 3.2.1). (Section 3.2.1).
3.2.1. Signed Transaction Attributes 3.2.1. Signed Transaction Attributes
At a minimum, all messages MUST contain the following At a minimum, all messages MUST contain the following
authenticatedAttributes: authenticatedAttributes:
o A transactionID attribute (see Section 3.2.1.1). o A transactionID attribute (see Section 3.2.1.1).
o A messageType attribute (see Section 3.2.1.2). o A messageType attribute (see Section 3.2.1.2).
o A fresh senderNonce attribute (see Section 3.2.1.5). o A fresh senderNonce attribute (see Section 3.2.1.5). Note however
the comment about senderNonces and polling in Section 3.3.2
o Any attributes required by CMS. o Any attributes required by CMS.
If the message is a CertRep, it MUST also include the following If the message is a CertRep, it MUST also include the following
authenticatedAttributes: authenticatedAttributes:
o A pkiStatus attribute (see Section 3.2.1.3). o A pkiStatus attribute (see Section 3.2.1.3).
o A failInfo and optional failInfotext attribute (see o A failInfo and optional failInfotext attribute (see
Section 3.2.1.4) if pkiStatus = FAILURE. Section 3.2.1.4) if pkiStatus = FAILURE.
o A recipientNonce attribute (see Section 3.2.1.5) copied from the o A recipientNonce attribute (see Section 3.2.1.5) copied from the
senderNonce in the request that this is a response to. senderNonce in the request that this is a response to.
The following transaction attributes are encoded as authenticated The following transaction attributes are encoded as authenticated
attributes, and are carried in the SignerInfo for this Signed-Data. attributes, and are carried in the SignerInfo for this Signed-Data.
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| Attribute | Encoding | Comment | | Attribute | Encoding | Comment |
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| transactionID | PrintableString | Unique ID for this transaction | | transactionID | PrintableString | Unique ID for this |
| | | as a text string | | | | transaction as a text string |
| | | | | | | |
| messageType | PrintableString | Decimal value as a numeric | | messageType | PrintableString | Decimal value as a |
| | | text string | | | | numeric text string |
| | | | | | | |
| pkiStatus | PrintableString | Decimal value as a numeric | | pkiStatus | PrintableString | Decimal value as a |
| | | text string | | | | numeric text string |
| | | | | | | |
| failInfo | PrintableString | Decimal value as a numeric | | failInfo | PrintableString | Decimal value as a |
| | | text string | | | | numeric text string |
| | | | | | | |
| failInfoText | UTF8String | Descriptive text for the | | failInfoText | UTF8String | Descriptive text for the |
| | | failInfo value | | | | failInfo value |
| | | | | | | |
| senderNonce | OCTET STRING | Random nonce as a 16-byte | | senderNonce | OCTET STRING | Random nonce as a 16-byte |
| | | binary data string | | | | binary data string |
| | | | | | | |
| recipientNonce | OCTET STRING | Random nonce as a 16-byte | | recipientNonce | OCTET STRING | Random nonce as a |
| | | binary data string | | | | 16-byte binary data string |
+----------------+-----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
The OIDs used for these attributes are as follows: The OIDs used for these attributes are as follows:
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| Name | ASN.1 Definition | | Name | ASN.1 Definition |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 |
| | VeriSign(113733)} | | | VeriSign(113733)} |
| | | | | |
| id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} |
skipping to change at page 17, line 7 skipping to change at page 17, line 7
A PKI operation is a transaction consisting of the messages exchanged A PKI operation is a transaction consisting of the messages exchanged
between a client and the CA. The transactionID is a text string between a client and the CA. The transactionID is a text string
provided by the client when starting a transaction. The client MUST provided by the client when starting a transaction. The client MUST
use a unique string as the transaction identifier, encoded as a use a unique string as the transaction identifier, encoded as a
PrintableString, which MUST be used for all PKI messages exchanged PrintableString, which MUST be used for all PKI messages exchanged
for a given operation such as a certificate issue. for a given operation such as a certificate issue.
Note that the transactionID must be unique, but not necessarily Note that the transactionID must be unique, but not necessarily
randomly generated. For example it may be a value assigned by the CA randomly generated. For example it may be a value assigned by the CA
(alongside the challengePassword) as an equivalent to the traditional to allow the client to be identified by their transactionID, using a
user name + password, so that the client is identified by their value such as the client device's EUI or RTU ID or a similar unique
transactionID. This can be useful when the client doesn't have a identifier. This can be useful when the client doesn't have a pre-
pre-assigned Distinguished Name that the CA can identify their assigned Distinguished Name that the CA can identify their request
request through, for example when enrolling SCADA devices. through, for example when enrolling SCADA devices.
3.2.1.2. messageType 3.2.1.2. messageType
The messageType attribute specifies the type of operation performed The messageType attribute specifies the type of operation performed
by the transaction. This attribute MUST be included in all PKI by the transaction. This attribute MUST be included in all PKI
messages. The following message types are defined: messages. The following message types are defined:
o CertRep ("3") -- Response to certificate or CRL request. o CertRep ("3") -- Response to certificate or CRL request.
o RenewalReq ("17") -- PKCS #10 certificate request authenticated o RenewalReq ("17") -- PKCS #10 certificate request authenticated
with an existing certificate. with an existing certificate.
o PKCSReq ("19") -- PKCS #10 certificate request authenticated with o PKCSReq ("19") -- PKCS #10 certificate request authenticated with
a password. a shared secret.
o CertPoll ("20") -- Certificate polling in manual enrolment. o CertPoll ("20") -- Certificate polling in manual enrolment.
o GetCert ("21") -- Retrieve a certificate. o GetCert ("21") -- Retrieve a certificate.
o GetCRL ("22") -- Retrieve a CRL. o GetCRL ("22") -- Retrieve a CRL.
Undefined message types MUST BE treated as an error. Message types not defined above MUST be treated as an error unless
their use has been negotiated through GetCACaps (Section 3.5.1).
3.2.1.3. pkiStatus 3.2.1.3. pkiStatus
All response messages MUST include transaction status information, All response messages MUST include transaction status information,
which is defined as a pkiStatus attribute: which is defined as a pkiStatus attribute:
o SUCCESS ("0") -- Request granted. o SUCCESS ("0") -- Request granted.
o FAILURE ("2") -- Request rejected. In this case the failInfo o FAILURE ("2") -- Request rejected. In this case the failInfo
attribute, as defined in Section 3.2.1.4, MUST also be present. attribute, as defined in Section 3.2.1.4, MUST also be present.
o PENDING ("3") -- Request pending for manual approval. o PENDING ("3") -- Request pending for manual approval.
Undefined pkiStatus attributes MUST be treated as an error. PKI status values not defined above MUST be treated as an error
unless their use has been negotiated through GetCACaps
(Section 3.5.1).
3.2.1.4. failInfo and failInfoText 3.2.1.4. failInfo and failInfoText
The failInfo attribute MUST contain one of the following failure The failInfo attribute MUST contain one of the following failure
reasons: reasons:
o badAlg ("0") -- Unrecognized or unsupported algorithm. o badAlg ("0") -- Unrecognized or unsupported algorithm.
o badMessageCheck ("1") -- Integrity check (meaning signature o badMessageCheck ("1") -- Integrity check (meaning signature
verification of the CMS message) failed. verification of the CMS message) failed.
o badRequest ("2") -- Transaction not permitted or supported. o badRequest ("2") -- Transaction not permitted or supported.
o badTime ("3") -- The signingTime attribute from the CMS o badTime ("3") -- The signingTime attribute from the CMS
authenticatedAttributes was not sufficiently close to the system authenticatedAttributes was not sufficiently close to the system
time (this failure code is present for legacy reasons and is time. This condition may occur if the CA is concerned about
unlikely to be encountered in practice). replays of old messages.
o badCertId ("4") -- No certificate could be identified matching the o badCertId ("4") -- No certificate could be identified matching the
provided criteria. provided criteria.
Failure reasons not defined above MUST be treated as an error unless
their use has been negotiated through GetCACaps (Section 3.5.1).
The failInfoText is a free-form UTF-8 text string that provides The failInfoText is a free-form UTF-8 text string that provides
further information in the case of pkiStatus = FAILURE. In further information in the case of pkiStatus = FAILURE. In
particular it may be used to provide details on why a certificate particular it may be used to provide details on why a certificate
request was not granted that go beyond what's provided by the near- request was not granted that go beyond what's provided by the near-
universal failInfo = badRequest status. Since this is a free-form universal failInfo = badRequest status. Since this is a free-form
text string intended for interpretation by humans, implementations text string intended for interpretation by humans, implementations
SHOULD NOT assume that it has any type of machine-processable SHOULD NOT assume that it has any type of machine-processable
content. content.
3.2.1.5. senderNonce and recipientNonce 3.2.1.5. senderNonce and recipientNonce
The senderNonce and recipientNonce attributes are a 16 byte random The senderNonce and recipientNonce attributes are a 16 byte random
number generated for each transaction. These are intended to prevent number generated for each transaction. These are intended to prevent
replay attacks. replay attacks.
When a sender sends a PKI message to a recipient, a fresh senderNonce When a sender sends a PKI message to a recipient, a fresh senderNonce
MUST be included in the message. The recipient MUST copy the MUST be included in the message. The recipient MUST copy the
senderNonce into the recipientNonce of the reply as a proof of senderNonce into the recipientNonce of the reply as a proof of
liveliness. The original sender MUST verify that the recipientNonce liveliness. The original sender MUST verify that the recipientNonce
of the reply matches the senderNonce it sent in the request. If the of the reply matches the senderNonce it sent in the request. If the
nonce does not match, the message MUST be rejected. nonce does not match then the message MUST be rejected.
Note that since SCEP exchanges consist of a single request followed Note that since SCEP exchanges consist of a single request followed
by a single response, the use of distinct sender and recipient nonces by a single response, the use of distinct sender and recipient nonces
is redundant since the client sends a nonce in its request and the CA is redundant since the client sends a nonce in its request and the CA
responds with the same nonce in its reply. In effect there's just a responds with the same nonce in its reply. In effect there's just a
single nonce, identified as senderNonce in the client's request and single nonce, identified as senderNonce in the client's request and
recipientNonce in the CA's reply. recipientNonce in the CA's reply.
3.2.2. SCEP pkcsPKIEnvelope 3.2.2. SCEP pkcsPKIEnvelope
skipping to change at page 18, line 45 skipping to change at page 19, line 4
single nonce, identified as senderNonce in the client's request and single nonce, identified as senderNonce in the client's request and
recipientNonce in the CA's reply. recipientNonce in the CA's reply.
3.2.2. SCEP pkcsPKIEnvelope 3.2.2. SCEP pkcsPKIEnvelope
The information portion of a SCEP message is carried inside an The information portion of a SCEP message is carried inside an
EnvelopedData content type, as defined in CMS, with the following EnvelopedData content type, as defined in CMS, with the following
restrictions: restrictions:
o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}).
o encryptedContent MUST be the SCEP message being transported (see o encryptedContent MUST be the SCEP message being transported (see
Section 4), and must match the messageType authenticated Attribute Section 4), and must match the messageType authenticated Attribute
in the pkiMessage. in the pkiMessage.
3.3. SCEP pkiMessage types 3.3. SCEP pkiMessage types
All of the messages in this section are pkiMessages (Section 3.2), All of the messages in this section are pkiMessages (Section 3.2),
where the type of the message MUST be specified in the 'messageType' where the type of the message MUST be specified in the 'messageType'
authenticated Attribute. Each section defines a valid message type, authenticated Attribute. Each section defines a valid message type,
the corresponding messageData formats, and mandatory authenticated the corresponding messageData formats, and mandatory authenticated
attributes for that type. attributes for that type.
3.3.1. PKCSReq/RenewalReq 3.3.1. PKCSReq/RenewalReq
The messageData for this type consists of a PKCS #10 Certificate The messageData for this type consists of a PKCS #10 Certificate
Request. The certificate request MUST contain at least the following Request. The certificate request MUST contain at least the following
items: items:
o The subject Distinguished Name. o The subject Distinguished Name.
o The subject public key. o The subject public key.
o For a PKCSReq and if authorisation based on a password is being o For a PKCSReq and if authorisation based on a shared secret is
used, a challengePassword attribute. being used, a challengePassword attribute.
In addition to the authenticatedAttributes required for a valid CMS
message, the pkiMessage MUST include the following attributes:
o A transactionID attribute (Section 3.2.1.1). In addition the message must contain the the authenticatedAttributes
o A messageType attribute (Section 3.2.1.2) set to PKCSReq or specified in Section 3.2.1.
RenewalReq as appropriate.
o A fresh senderNonce attribute (Section 3.2.1.5).
3.3.2. CertRep 3.3.2. CertRep
The messageData for this type consists of a degenerate certificates- The messageData for this type consists of a degenerate certificates-
only CMS Signed-Data message (Section 3.4). The exact content only CMS Signed-Data message (Section 3.4). The exact content
required for the reply depends on the type of request that this required for the reply depends on the type of request that this
message is a response to. The request types are detailed in message is a response to. The request types are detailed in
Section 3.3.2.1 and in Section 4. Section 3.3.2.1 and in Section 4. In addition the message must
contain the the authenticatedAttributes specified in Section 3.2.1.
In addition to the authenticatedAttributes required for a valid CMS
message, this pkiMessage MUST include the following attributes:
o The transactionID attribute (Section 3.2.1.1) copied from the
request that this is a response to.
o A messageType attribute (Section 3.2.1.2) set to CertRep.
o A recipientNonce attribute (Section 3.2.1.5) copied from the
senderNonce in the request that this is a response to.
o A pkiStatus attribute (Section 3.2.1.3) set to the status of the
reply.
Earlier versions of this specification required that this message Earlier versions of this specification required that this message
include a senderNonce alongside the recipientNonce, which was to be include a senderNonce alongside the recipientNonce, which was to be
used to chain to subsequent polling operations. However if a single used to chain to subsequent polling operations. However if a single
message was lost during the potentially extended interval over which message was lost during the potentially extended interval over which
polling could take place (see Section 5 for an example of this) then polling could take place (see Section 5 for an example of this) then
if the implementation were to enforce this requirement the overall if the implementation were to enforce this requirement the overall
transaction would fail even though nothing had actually gone wrong. transaction would fail even though nothing had actually gone wrong.
Because of this issue, implementations mostly ignored the requirement Because of this issue, implementations mostly ignored the requirement
to carry this nonce over to subsequent polling messages or to verify to carry this nonce over to subsequent polling messages or to verify
its presence. Current versions of the specification no longer its presence. More recent versions of the specification no longer
require the chaining of nonces across polling operations. require the chaining of nonces across polling operations.
3.3.2.1. CertRep SUCCESS 3.3.2.1. CertRep SUCCESS
When the pkiStatus attribute is set to SUCCESS, the messageData for When the pkiStatus attribute is set to SUCCESS, the messageData for
this message consists of a degenerate certificates-only CMS Signed- this message consists of a degenerate certificates-only CMS Signed-
Data message (Section 3.4). The content of this degenerate Data message (Section 3.4). The content of this degenerate
certificates-only Signed-Data depends on what the original request certificates-only Signed-Data depends on what the original request
was, as outlined below. was, as outlined below.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Request-type | Reply-contents | | Request-type | Reply-contents |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| PKCSReq | The reply MUST contain at least the issued | | PKCSReq | The reply MUST contain at least the issued |
| | certificate in the certificates field of the | | | certificate in the certificates field of the |
| | Signed-Data. The reply MAY contain additional | | | Signed-Data. The |
| | certificates, but the issued certificate MUST be | | | reply MAY contain additional certificates, but the |
| | the leaf certificate. | | | issued |
| | certificate MUST be the leaf certificate. |
| | | | | |
| RenewalReq | Same as PKCSReq | | RenewalReq | Same as PKCSReq |
| | | | | |
| CertPoll | Same as PKCSReq | | CertPoll | Same as PKCSReq |
| | | | | |
| GetCert | The reply MUST contain at least the requested | | GetCert | The reply MUST contain at least the requested |
| | certificate in the certificates field of the | | | certificate in the certificates field of the |
| | Signed-Data. The reply MAY contain additional | | | Signed-Data. The |
| | certificates, but the requested certificate MUST | | | reply MAY contain additional certificates, but the |
| | be the leaf certificate. | | | requested certificate MUST be the leaf |
| | certificate. |
| | | | | |
| GetCRL | The reply MUST contain the CRL in the crls field | | GetCRL | The reply MUST contain the CRL in the crls field |
| | of the Signed-Data. | | | of the Signed-Data. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
3.3.2.2. CertRep FAILURE 3.3.2.2. CertRep FAILURE
When the pkiStatus attribute is set to FAILURE, the reply MUST also When the pkiStatus attribute is set to FAILURE, the reply MUST also
contain a failInfo (Section 3.2.1.4) attribute set to the appropriate contain a failInfo (Section 3.2.1.4) attribute set to the appropriate
error condition describing the failure. The reply MAY also contain a error condition describing the failure. The reply MAY also contain a
skipping to change at page 21, line 20 skipping to change at page 21, line 13
(Section 3.2.2) MUST be omitted. (Section 3.2.2) MUST be omitted.
3.3.3. CertPoll (GetCertInitial) 3.3.3. CertPoll (GetCertInitial)
This message is used for certificate polling. For unknown reasons it This message is used for certificate polling. For unknown reasons it
was referred to as "GetCertInitial" in earlier versions of this was referred to as "GetCertInitial" in earlier versions of this
specification. The messageData for this type consists of an specification. The messageData for this type consists of an
IssuerAndSubject: IssuerAndSubject:
issuerAndSubject ::= SEQUENCE { issuerAndSubject ::= SEQUENCE {
issuer Name, issuer Name,
subject Name subject Name
} }
The issuer is set to the subjectName of the CA (in other words the The issuer is set to the subjectName of the CA (in other words the
intended issuerName of the certificate that's being requested). The intended issuerName of the certificate that's being requested). The
subject is set to the subjectName used when requesting the subject is set to the subjectName used when requesting the
certificate. certificate.
Note that both of these fields are redundant, the CA is identified by Note that both of these fields are redundant, the CA is identified by
the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by the recipientInfo in the pkcsPKIEnvelope (or in most cases simply by
the server that the message is being sent to) and the client/ the server that the message is being sent to) and the client/
transaction being polled is identified by the transactionID. Both of transaction being polled is identified by the transactionID. Both of
these fields can be processed by the CA without going through the these fields can be processed by the CA without going through the
cryptographically expensive process od unwrapping and processing the cryptographically expensive process of unwrapping and processing the
issuerAndSubject. For this reason implementations SHOULD assume that issuerAndSubject. For this reason implementations SHOULD assume that
the polling operation will be controlled by the recipientInfo and the polling operation will be controlled by the recipientInfo and
transactionID rather than the contents of the messageData. transactionID rather than the contents of the messageData. In
addition the message must contain the the authenticatedAttributes
In addition to the authenticatedAttributes required for a valid CMS specified in Section 3.2.1.
message, this pkiMessage MUST include the following attributes:
o The same transactionID (Section 3.2.1.1) attribute from the
original PKCSReq/RenewalReq message.
o A messageType attribute (Section 3.2.1.2) set to CertPoll.
o A fresh senderNonce attribute (Section 3.2.1.5).
3.3.4. GetCert and GetCRL 3.3.4. GetCert and GetCRL
The messageData for these types consist of an IssuerAndSerialNumber The messageData for these types consist of an IssuerAndSerialNumber
as defined in CMS which uniquely identifies the certificate being as defined in CMS which uniquely identifies the certificate being
requested, either the certificate itself for GetCert or its requested, either the certificate itself for GetCert or its
revocation status via a CRL for GetCRL. In addition to the revocation status via a CRL for GetCRL. In addition the message must
authenticatedAttributes required for a valid CMS message, this contain the the authenticatedAttributes specified in Section 3.2.1.
pkiMessage MUST include the following attributes:
o A transactionID attribute (Section 3.2.1.1).
o A messageType attribute (Section 3.2.1.2) set to GetCert or
GetCRL.
o A fresh senderNonce attribute (Section 3.2.1.5).
A self-signed certificate MAY be used in the signed envelope. This
enables the client to request their own certificate if they were
unable to store it previously.
These message types, while included here for completeness, apply These message types, while included here for completeness, apply
unnecessary cryptography and messaging overhead to the simple task of unnecessary cryptography and messaging overhead to the simple task of
transferring a certificate or CRL (see Section 8.7). Implementations transferring a certificate or CRL (see Section 8.8). Implementations
SHOULD prefer HTTP certificate-store access [11] or LDAP over the use SHOULD prefer HTTP certificate-store access [17] or LDAP over the use
of these messages. of these messages.
3.4. Degenerate certificates-only CMS Signed-Data 3.4. Degenerate certificates-only CMS Signed-Data
CMS includes a degenerate case of the Signed-Data content type in CMS includes a degenerate case of the Signed-Data content type in
which there are no signers. The use of such a degenerate case is to which there are no signers. The use of such a degenerate case is to
disseminate certificates and CRLs. For SCEP the content field of the disseminate certificates and CRLs. For SCEP the content field of the
ContentInfo value of a degenerate certificates-only Signed-Data MUST ContentInfo value of a degenerate certificates-only Signed-Data MUST
be omitted. be omitted. When carrying certificates, the certificates are
included in the 'certificates' field of the Signed-Data. When
When carrying certificates, the certificates are included in the carrying a CRL, the CRL is included in the 'crls' field of the
'certificates' field of the Signed-Data. When carrying a CRL, the Signed-Data.
CRL is included in the 'crls' field of the Signed-Data.
3.5. CA Capabilities 3.5. CA Capabilities
In order to provide support for future enhancements to the protocol, In order to provide support for future enhancements to the protocol,
CAs MUST implement the GetCACaps message to allow clients to query CAs MUST implement the GetCACaps message to allow clients to query
which functionality is available from the CA. which functionality is available from the CA.
3.5.1. GetCACaps HTTP Message Format 3.5.1. GetCACaps HTTP Message Format
This message requests capabilities from a CA, with the format: This message requests capabilities from a CA, with the format:
"GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
with the message components as described in Section 4. as described in Section 4.1.
3.5.2. CA Capabilities Response Format 3.5.2. CA Capabilities Response Format
The response for a GetCACaps message is a list of CA capabilities, in The response for a GetCACaps message is a list of CA capabilities, in
plain text, separated by <CR><LF> or <LF> characters, as follows plain text and in any order, separated by <CR><LF> or <LF>
(quotation marks are NOT sent): characters. This specification defines the following keywords
(quotation marks are not sent):
+--------------------+----------------------------------------------+ +--------------------+----------------------------------------------+
| Keyword | Description | | Keyword | Description |
+--------------------+----------------------------------------------+ +--------------------+----------------------------------------------+
| "AES" | CA supports the AES encryption algorithm. | | "AES" | CA supports the AES128-CBC encryption |
| | algorithm. |
| | | | | |
| "DES3" | CA supports the triple DES encryption | | "DES3" | CA supports the triple DES-CBC encryption |
| | algorithm. | | | algorithm. |
| | | | | |
| "GetNextCACert" | CA supports the GetNextCACert message. | | "GetNextCACert" | CA supports the GetNextCACert |
| | message. |
| | | | | |
| "POSTPKIOperation" | CA supports PKIOPeration messages sent via | | "POSTPKIOperation" | CA supports PKIOPeration messages sent |
| | HTTP POST. | | | via HTTP POST. |
| | | | | |
| "Renewal" | CA supports the Renewal CA operation. | | "Renewal" | CA supports the Renewal CA operation. |
| | | | | |
| "SHA-1" | CA supports the SHA-1 hashing algorithm. | | "SHA-1" | CA supports the SHA-1 hashing algorithm. |
| | | | | |
| "SHA-256" | CA supports the SHA-256 hashing algorithm. | | "SHA-256" | CA supports the SHA-256 hashing algorithm. |
| | | | | |
| "SHA-512" | CA supports the SHA-512 hashing algorithm. | | "SHA-512" | CA supports the SHA-512 hashing algorithm. |
| | | | | |
| "SCEPStandard" | CA supports all mandatory-to-implement | | "SCEPStandard" | CA supports all mandatory-to-implement |
| | sections of the SCEP standard. This keyword | | | sections of the SCEP standard. This keyword |
| | implies "AES", "POSTPKIOperation", and | | | implies "AES", |
| | "SHA-256", as well as the provisions of | | | "POSTPKIOperation", and "SHA-256", as well |
| | as the provisions of |
| | Section 2.9. | | | Section 2.9. |
+--------------------+----------------------------------------------+ +--------------------+----------------------------------------------+
The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES The table above lists all of the keywords that are defined in this
in preference to triple DES if they are supported by the CA. specification. A CA MAY provide additional keywords advertising
Although the CMS format allows any form of AES and SHA-2 to be further capabilities and functionality. A client MUST be able to
specified, in the interests of interoperability the de facto accept and ignore any unknown keywords that might be sent by a CA.
The CA MUST use the text case specified here, but clients SHOULD
ignore the text case when processing this message. Clients MUST
accept the standard HTTP-style <CR><LF>-delimited text as well as the
<LF>- delimited text specified in an earlier version of this
specification.
The client SHOULD use SHA-256 in preference to SHA-1 hashing and
AES128-CBC in preference to triple DES-CBC if they are supported by
the CA. Although the CMS format allows any form of AES and SHA-2 to
be specified, in the interests of interoperability the de facto
universal standards of AES128-CBC and SHA-256 SHOULD be used. universal standards of AES128-CBC and SHA-256 SHOULD be used.
Announcing some of these capabilities individually is redundant since Announcing some of these capabilities individually is redundant since
they're required as mandatory-to-implement functionality (see they're required as mandatory-to-implement functionality (see
Section 2.9) whose presence as a whole is signalled by the Section 2.9) whose presence as a whole is signalled by the
"SCEPStandard" capability, but it may be useful to announce them in "SCEPStandard" capability, but it may be useful to announce them in
order to deal with old implementations that would otherwise default order to deal with older implementations that would otherwise default
to obsolete, insecure algorithms and mechanisms. to obsolete, insecure algorithms and mechanisms.
The CA MUST use the text case specified here, but clients SHOULD
ignore the text case when processing this message. Clients MUST
accept the standard HTTP-style <CR><LF>-delimited text as well as the
<LF>- delimited text specified in an earlier version of this
specification. 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 it SHOULD return an If the CA supports none of the above capabilities it SHOULD return an
empty message. A CA MAY simply return an HTTP error. A client that empty message. A CA MAY simply return an HTTP error. A client that
receives an empty message or an HTTP error SHOULD interpret the receives an empty message or an HTTP error SHOULD interpret the
response as if none of the requested capabilities are supported by response as if none of the capabilities listed are supported by the
the CA. CA.
(Note that at least one widely-deployed server implementation Note that at least one widely-deployed server implementation supports
supports several of the above operations but doesn't support the several of the above operations but doesn't support the GetCACaps
GetCACaps message to indicate that it supports them, and will close message to indicate that it supports them, and will close the
the connection if sent a GetCACaps message. This means that the connection if sent a GetCACaps message. This means that the
equivalent of GetCACaps must be performed through server equivalent of GetCACaps must be performed through server
fingerprinting, which can be done using the ID string "Microsoft- fingerprinting, which can be done using the ID string "Microsoft-
IIS". Newer versions of the same server, if sent a SCEP request IIS". Newer versions of the same server, if sent a SCEP request
using AES and SHA-2, will respond with an invalid response that can't using AES and SHA-2, will respond with an invalid response that can't
be decrypted, requiring the use of 3DES and SHA-1 in order to obtain be decrypted, requiring the use of 3DES and SHA-1 in order to obtain
a response that can be processed even if AES and/or SHA-2 are a response that can be processed even if AES and/or SHA-2 are
allegedly supported. In addition the server will generate CA allegedly supported. In addition the server will generate CA
certificates that only have one, but not both, of the keyEncipherment certificates that only have one, but not both, of the keyEncipherment
and digitalSignature keyUsage flags set, requiring that the client and digitalSignature keyUsage flags set, requiring that the client
ignore the keyUsage flags in order to use the certificates for SCEP). ignore the keyUsage flags in order to use the certificates for SCEP.
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD The Content-type of the reply SHOULD be "text/plain". Clients SHOULD
ignore the Content-type, as older implementations of SCEP may send ignore the Content-type, as older implementations of SCEP may send
various Content-types. various Content-types.
Example: Example:
GET /cgi-bin/pkiclient.exe?operation=GetCACaps GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1
might return: might return:
AES AES
GetNextCACert GetNextCACert
POSTPKIOperation POSTPKIOperation
SCEPStandard SCEPStandard
SHA-256 SHA-256
This means that the CA supports modern crypto algorithms, the This means that the CA supports modern crypto algorithms, the
GetNextCACert message, allows PKIOperation messages (PKCSReq/ GetNextCACert message, allows PKIOperation messages (PKCSReq/
RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST, and
is compliant with the final version of the SCEP standard. is compliant with the final version of the SCEP standard.
4. SCEP Transactions 4. SCEP Transactions
This section describes the SCEP Transactions and their HTTP [4] This section describes the SCEP Transactions and their HTTP [11]
transport mechanism. transport mechanism.
Note that SCEP doesn't follow best current practices on usage of
HTTP. In particular it recommends ignoring some Media Types and
hardcodes specific URI paths. Guidance on the appropriate
application of HTTP in these circumstances may be found in [16].
4.1. HTTP POST and GET Message Formats 4.1. HTTP POST and GET Message Formats
SCEP uses the HTTP "POST" and "GET" messages to exchange information SCEP uses the HTTP "POST" and "GET" HTTP methods [11] to exchange
with the CA. The following defines the syntax of HTTP POST and GET information with the CA. The following defines the ABNF syntax of
messages sent from a client to a CA: HTTP POST and GET methods sent from a client to a CA:
"POST" CGI-PATH CGI-PROG "?operation=" OPERATION POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION
"GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE SP HTTP-version CRLF
GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
"&message=" MESSAGE SP HTTP-version CRLF
where: where:
o CGI-PATH defines the path to invoke the CGI program that parses o SCEPPATH is the HTTP URL path for accessing the CA. Clients
the request. SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe"
o CGI-PROG is set to be the string "pkiclient.exe". This is unless directed to do otherwise by the CA.
intended to be the program that the CA will use to handle the SCEP
transactions.
o OPERATION depends on the SCEP transaction and is defined in the o OPERATION depends on the SCEP transaction and is defined in the
following sections. following sections.
o HTTP-version is the HTTP version string, which is "HTTP/1.1" for
[11].
The CA will typically ignore CGI-PATH and/or CGI-PROG since it's o SP and CRLF are space and carriage return/linefeed as defined in
unlikely to be issuing certificates via a web server. Clients SHOULD [6].
set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe"
unless directed to do otherwise by the CA. The CA SHOULD ignore the The CA will typically ignore SCEPPATH since it's unlikely to be
CGI-PATH and CGI-PROG unless its precise format is critical to the issuing certificates via a web server. Clients SHOULD set SCEPPATH
CA's operation. to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do
otherwise by the CA. The CA SHOULD ignore the SCEPPATH unless its
precise format is critical to the CA's operation.
Early SCEP drafts performed all communications via "GET" messages, Early SCEP drafts performed all communications via "GET" messages,
including non-idempotent ones that should have been sent via "POST" including non-idempotent ones that should have been sent via "POST"
messages. This has caused problems because of the way that the messages, see [16] for details. This has caused problems because of
(supposedly) idempotent GET interacts with caches and proxies, and the way that the (supposedly) idempotent GET interacts with caches
because the extremely large GET requests created by encoding CMS and proxies, and because the extremely large GET requests created by
messages may be truncated in transit. These issues are typically not encoding CMS messages may be truncated in transit. These issues are
visible when testing on a LAN, but crop up during deployment over typically not visible when testing on a LAN, but crop up during
WANs. If the remote CA supports POST, the CMS-encoded SCEP messages deployment over WANs. If the remote CA supports POST, the CMS-
MUST be sent via HTTP POST instead of HTTP GET. This applies to any encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET.
SCEP message except GetCACert, GetNextCACert, and GetCACaps, and This applies to any SCEP message except GetCACert, GetNextCACert, and
avoids the need for base64- and URL-encoding that's required for GET GetCACaps, and avoids the need for base64- and URL-encoding that's
messaging. The client can verify that the CA supports SCEP messages required for GET messaging. The client can verify that the CA
via POST by looking for the "POSTPKIOperation" capability (See supports SCEP messages via POST by looking for the "SCEPStandard" or
Section 3.5.2). "POSTPKIOperation" capability (See Section 3.5.2).
If a client or CA uses HTTP GET and encounters HTTP-related problems If a client or CA uses HTTP GET and encounters HTTP-related problems
such as messages being truncated, seeing errors such as HTTP 414 such as messages being truncated, seeing errors such as HTTP 414
("Request URI too long"), or simply having the message not sent/ ("Request URI too long"), or simply having the message not sent/
received at all, when standard requests to the server (for example received at all, when standard requests to the server (for example
via a web browser) work, then this is a symptom of the problematic via a web browser) work, then this is a symptom of the problematic
use of HTTP GET. The solution to this problem is to update the use of HTTP GET. The solution to this problem is to update the
implementation to use HTTP POST instead. In addition when using GET implementation to use HTTP POST instead. In addition when using GET
it's recommended to test your implementation over the public internet it's recommended to test the implementation from as many different
from as many locations as possible to determine whether the use of network locations as possible to determine whether the use of GET
GET will cause problems with communications. will cause problems with communications.
When using GET messages to communicate binary data, base64 encoding When using GET messages to communicate binary data, base64 encoding
as specified in [2] MUST be used. The base64 encoded data is as specified in [9] Section 4 MUST be used. The base64 encoded data
distinct from "base64url" and may contain URI reserved characters, is distinct from "base64url" and may contain URI reserved characters,
thus it MUST be escaped as specified in [8] in addition to being thus it MUST be escaped as specified in [15] in addition to being
base64 encoded. Finally, the encoded data is inserted into the base64 encoded. Finally, the encoded data is inserted into the
MESSAGE portion of the HTTP GET request. MESSAGE portion of the HTTP GET request.
4.2. Get CA Certificate 4.2. Get CA Certificate
To get the CA certificate(s), the client sends a GetCACert message to To get the CA certificate(s), the client sends a GetCACert message to
the CA. The OPERATION MUST be set to "GetCACert". There is no the CA. The OPERATION MUST be set to "GetCACert". There is no
request data associated with this message. request data associated with this message.
4.2.1. Get CA Certificate Response Message Format 4.2.1. Get CA Certificate Response Message Format
skipping to change at page 27, line 36 skipping to change at page 27, line 43
<binary CMS> <binary CMS>
4.3. Certificate Enrolment/Renewal 4.3. Certificate Enrolment/Renewal
A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a
certificate enrolment or renewal transaction. The OPERATION MUST be certificate enrolment or renewal transaction. The OPERATION MUST be
set to "PKIOperation". Note that when used with HTTP POST, the only set to "PKIOperation". Note that when used with HTTP POST, the only
OPERATION possible is "PKIOperation", so many CAs don't check this OPERATION possible is "PKIOperation", so many CAs don't check this
value or even notice its absence. When implemented using HTTP POST value or even notice its absence. When implemented using HTTP POST
the message might look as follows: the message is sent with a Content-Type of "application/x-pki-
message" and might look as follows:
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
Content-Length: <length of data> Content-Length: <length of data>
Content-Type: application/x-pki-message
<binary CMS data> <binary CMS data>
When implemented using HTTP GET this might look as follows: When implemented using HTTP GET this might look as follows:
GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \ GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \
message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \ message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1 IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1
4.3.1. Certificate Enrolment/Renewal Response Message 4.3.1. Certificate Enrolment/Renewal Response Message
If the request is granted, a CertRep message (Section 3.3.2) with If the request is granted, a CertRep SUCCESS message
pkiStatus set to SUCCESS is returned. The reply MUST also contain (Section 3.3.2.1) is returned. If the request is rejected, a CertRep
the certificate (and MAY contain any other certificates needed by the FAILURE message (Section 3.3.2.2) is returned. If the CA is
client). The issued certificate MUST be the first in the list. configured to manually authenticate the client, a CertRep PENDING
message (Section 3.3.2.3) MAY be returned. The CA MAY return a
If the request is rejected, a CertRep message (Section 3.3.2) with PENDING for other reasons.
pkiStatus set to FAILURE is returned. The reply MUST also contain a
failInfo attribute and MAY contain a failInfoText attribute.
If the the CA is configured to manually authenticate the client, a
CertRep message (Section 3.3.2) with pkiStatus set to PENDING MAY be
returned. The CA MAY return a PENDING for other reasons.
The response will have a Content-Type of "application/x-pki-message". The response will have a Content-Type of "application/x-pki-message".
"Content-Type: application/x-pki-message" "Content-Type: application/x-pki-message"
<binary CertRep message> <binary CertRep message>
4.4. Poll for Client Initial Certificate 4.4. Poll for Client Initial Certificate
When the client receives a CertRep message with pkiStatus set to When the client receives a CertRep message with pkiStatus set to
PENDING, it will enter the polling state by periodically sending PENDING, it will enter the polling state by periodically sending
CertPoll messages to the CA until either the request is granted and CertPoll messages to the CA until either the request is granted and
the certificate is sent back or the request is rejected or some the certificate is sent back or the request is rejected or some
preconfigured time limit for polling or maximum number of polls is preconfigured time limit for polling or maximum number of polls is
exceeded. The OPERATION MUST be set to "PKIOperation". exceeded. The OPERATION MUST be set to "PKIOperation".
CertPoll messages exchanged during the polling period MUST carry the CertPoll messages exchanged during the polling period MUST carry the
same transactionID attribute as the previous PKCSReq/RenewalReq. A same transactionID attribute as the previous PKCSReq/RenewalReq. A
CA receiving a CertPoll for which it does not have a matching CA receiving a CertPoll for which it does not have a matching
PKCSReq/RenewalReq MUST ignore this request. PKCSReq/RenewalReq MUST reject this request.
Since at this time the certificate has not been issued, the client Since at this time the certificate has not been issued, the client
can only use its own subject name (which was contained in the can only use its own subject name (which was contained in the
original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled
certificate request (but see the note on identification during certificate request (but see the note on identification during
polling in Section 3.3.3). In theory there can be multiple polling in Section 3.3.3). In theory there can be multiple
outstanding requests from one client (for example, if different keys outstanding requests from one client (for example, if different keys
and different key-usages were used to request multiple certificates), and different key-usages were used to request multiple certificates),
so the transactionID must also be included to disambiguate between so the transactionID must also be included to disambiguate between
multiple requests. In practice however the client SHOULD NOT have multiple requests. In practice however the client SHOULD NOT have
skipping to change at page 30, line 9 skipping to change at page 30, line 11
When a CA certificate is about to expire, clients need to retrieve When a CA certificate is about to expire, clients need to retrieve
the CA's next CA certificate (i.e. the rollover certificate). This the CA's next CA certificate (i.e. the rollover certificate). This
is done via the GetNextCACert message. The OPERATION MUST be set to is done via the GetNextCACert message. The OPERATION MUST be set to
"GetNextCACert". There is no request data associated with this "GetNextCACert". There is no request data associated with this
message. message.
4.7.1. Get Next CA Response Message Format 4.7.1. Get Next CA Response Message Format
The response consists of a Signed-Data CMS message, signed by the The response consists of a Signed-Data CMS message, signed by the
current CA signing key. Clients MUST validate the signature on the current CA signing key. Clients MUST validate the signature on the
message before accepting any of its contents. The response will have message before trusting any of its contents. The response will have
a Content-Type of "application/x-x509-next-ca-cert". a Content-Type of "application/x-x509-next-ca-cert".
"Content-Type: application/x-x509-next-ca-cert" "Content-Type: application/x-x509-next-ca-cert"
<binary CMS> <binary CMS>
The content of the Signed-Data message is a degenerate certificates- The content of the Signed-Data message is a degenerate certificates-
only Signed-Data message (Section 3.4) containing the new CA only Signed-Data message (Section 3.4) containing the new CA
certificate(s) to be used when the current CA certificate expires. certificate(s) to be used when the current CA certificate expires.
If the CA does not have rollover certificate(s) it MUST reject the
request. It SHOULD also remove the GetNextCACert setting from the CA
capabilities returned by GetCACaps until it does have rollover
certificates.
5. SCEP Transaction Examples 5. SCEP Transaction Examples
The following section gives several examples of client to CA The following section gives several examples of client to CA
transactions. Client actions are indicated in the left column, CA transactions. Client actions are indicated in the left column, CA
actions are indicated in the right column, and the transactionID is actions are indicated in the right column, and the transactionID is
given in parentheses. The first transaction, for example, would read given in parentheses (for ease of reading small integer values have
like this: been used, in practice full transaction IDs would be used). The
first transaction, for example, would read like this:
"Client Sends PKCSReq message with transactionID 1 to the CA. The CA "Client Sends PKCSReq message with transactionID 1 to the CA. The CA
signs the certificate and constructs a CertRep Message containing the signs the certificate and constructs a CertRep Message containing the
signed certificate with a transaction ID 1. The client receives the signed certificate with a transaction ID 1. The client receives the
message and installs the certificate locally". message and installs the certificate locally".
5.1. Successful Transactions 5.1. Successful Transactions
Successful Enrolment Case: Automatic processing Successful Enrolment Case: Automatic processing
skipping to change at page 33, line 19 skipping to change at page 33, line 19
CertPoll (6) ----------> Still pending CertPoll (6) ----------> Still pending
<---------- CertRep (6) PENDING <---------- CertRep (6) PENDING
CertPoll (6) ----------> CA issues certificate CertPoll (6) ----------> CA issues certificate
X-------- CertRep(6) SUCCESS X-------- CertRep(6) SUCCESS
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
PKCSReq (7) ----------> There is already a valid PKCSReq (7) ----------> There is already a valid
certificate with this DN. certificate with this DN.
<---------- CertRep (7) FAILURE <---------- CertRep (7) FAILURE
Admin revokes certificate Admin revokes certificate
PKCSReq (7) ----------> CA issues new certificate PKCSReq (8) ----------> CA issues new certificate
<---------- CertRep (7) SUCCESS <---------- CertRep (8) SUCCESS
Client installs certificate Client installs certificate
Resync Case 4: Special-case variation of case 1 where the CertRep Resync Case 4: Special-case variation of case 1 where the CertRep
SUCCESS rather than the CertRep PENDING is lost (not recommended, use SUCCESS rather than the CertRep PENDING is lost (not recommended, use
PKCSReq to resync): PKCSReq to resync):
PKCSReq (8) ----------> Cert request goes into queue PKCSReq (9) ----------> Cert request goes into queue
<---------- CertRep (8) PENDING <---------- CertRep (9) PENDING
CertPoll (8) ----------> Still pending CertPoll (9) ----------> Still pending
<---------- CertRep (8) PENDING <---------- CertRep (9) PENDING
CertPoll (8) ----------> CA issues certificate CertPoll (9) ----------> CA issues certificate
X-------- CertRep(8) SIGNED CERT X-------- CertRep(9) SIGNED CERT
(Network outage) (Network outage)
(Client reconnects) (Client reconnects)
CertPoll (8) ----------> Certificate already issued CertPoll (9) ----------> Certificate already issued
<---------- CertRep (8) SUCCESS <---------- CertRep (9) SUCCESS
Client installs certificate Client installs certificate
As these examples indicate, resumption from an error via a resumed As these examples indicate, resumption from an error via a resumed
CertPoll is tricky due to the state that needs to be held by both the CertPoll is tricky due to the state that needs to be held by both the
client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to
implement since it's stateless and is identical for both polled and implement since it's stateless and is identical for both polled and
non-polled transactions, while a CertPoll resume treats the two non-polled transactions, while a CertPoll resume treats the two
differently (a non-polled transaction is resumed with a PKCSReq/ differently (a non-polled transaction is resumed with a PKCSReq/
RenewalReq, a polled transaction is resumed with a CertPoll). For RenewalReq, a polled transaction is resumed with a CertPoll). For
this reason error recovery SHOULD be handled via a new PKCSReq rather this reason error recovery SHOULD be handled via a new PKCSReq rather
than a resumed CertPoll. than a resumed CertPoll.
6. Contributors/Acknowledgements 6. Contributors/Acknowledgements
The editor would like to thank all of the previous editors, authors The editor would like to thank all of the previous editors, authors
and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David
Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their
work maintaining the draft over the years. Numerous other people work maintaining the draft over the years. The IETF reviewers
have contributed during the long life cycle of the draft and all provided much useful feedback that helped improve the draft, and in
deserve thanks. In addition several PKCS #7 / CMS libraries particular spotted a number of things that were present in SCEP
contributed to interoperability by doing the right thing despite what through established practice rather than by being explicitly
earlier SCEP drafts required. described in the text. Numerous other people have contributed during
the long life cycle of the draft and all deserve thanks. In addition
several PKCS #7 / CMS libraries contributed to interoperability by
doing the right thing despite what earlier SCEP drafts required.
The earlier authors would like to thank Peter William of ValiCert, The earlier authors would like to thank Peter William of ValiCert,
Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. Inc. (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc.
and Christopher Welles of IRE, Inc. for their contributions to early and Christopher Welles of IRE, Inc. for their contributions to early
versions of this protocol and this document. versions of this protocol and this document.
7. IANA Considerations 7. IANA Considerations
One object identifier for an arc to assign SCEP Attribute Identifiers One object identifier for an arc to assign SCEP Attribute Identifiers
was assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry: was assigned in the SMI Security for PKIX (1.3.6.1.5.5.7) registry,
Simple Certificate Enrollment Protocol Attributes denoted as id-scep:
id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 } id-scep OBJECT IDENTIFIER ::= { id-pkix TBD1 }
(Editor's note: When the OID is assigned, the values in the OID table
in Section 3.2 will also need to be updated).
This assignment created the new SMI Security for SCEP Attribute This assignment created the new SMI Security for SCEP Attribute
Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries
with references to this document: with references to this document:
id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 } id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }
(Editor's note: When the OID is assigned, the values in the OID table Entries in the registry are assigned according to the "Specification
in Section 3.2 will also need to be updated). Required" policy defined in [4].
Section 3.2.1.2 describes a SCEP Message Type Registry and
Section 3.5 describes a SCEP CA Capabilities Registry to be
maintained by the IANA, defining a number of such code point
identifiers. Entries in the registry are to be assigned according to
the "Specification Required" policy defined in [4].
The SCEP Message Type Registry has columns "Value," "Name,"
"Description," and "Reference". The "Value" entry is a small
positive integer, with the value "0" reserved.
The SCEP CA Capabilities Registry has columns "Keyword",
"Description", and "Reference". Although implementations SHOULD use
the SCEP CA Capabilities Registry, SCEP is often employed in
situations where this isn't possible. In this case private-use CA
capabilities may be specified using a unique prefix such as an
organisation identifier or domain name under the control of the
entity that defines the capability. For example the prefix would be
"Example.com-" and the complete capability would be "Example.com-
CapabilityName".
This document defines four media types for IANA registration:
"application/x-x509-ca-cert"
"application/x-x509-ca-ra-cert"
"application/x-x509-next-ca-cert"
"application/x-pki-message"
Note that these are grandfathered media types registered as per
Appendix A of [2]. Templates for registrations are specified below.
7.1. Registration of application/x-x509-ca-cert media type
Type name: application
Subtype name: x-x509-ca-cert
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: This media type contains a certificate, see
the Security Considerations section of [14]. There is no executable
content.
Interoperability considerations: This is a grandfathered registration
of an alias to application/pkix-cert (basically a single DER encoded
Certification Authority certificate), which is only used in SCEP.
Published specification: draft-gutmann-scep-15
Applications that use this media type: SCEP uses this media type when
returning a CA certificate.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): none
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the
Authors' Addresses section of draft-gutmann-scep-15
Intended usage: LIMITED USE
Restrictions on usage: SCEP protocol
Author: See the Authors' Addresses section of draft-gutmann-scep-15
Change controller: IETF
Provisional registration? No
7.2. Registration of application/x-x509-ca-ra-cert media type
Type name: application
Subtype name: x-x509-ca-ra-cert
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: This media type consists of a degenerate
certificates-only CMS Signed-Data message (Section 3.4) containing
the certificates, with the intermediate CA certificate(s) as the leaf
certificate(s). There is no executable content.
Interoperability considerations: This is a grandfathered registration
which is only used in SCEP.
Published specification: draft-gutmann-scep-15
Applications that use this media type: SCEP uses this media type when
returning CA Certificate Chain Response.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): none
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the
Authors' Addresses section of draft-gutmann-scep-15
Intended usage: LIMITED USE
Restrictions on usage: SCEP protocol
Author: See the Authors' Addresses section of draft-gutmann-scep-15
Change controller: IETF
Provisional registration? no
7.3. Registration of application/x-x509-next-ca-cert media type
Type name: application
Subtype name: x-x509-next-ca-cert
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: This media type consists of a Signed-Data
CMS message, signed by the current CA signing key. There is no
executable content.
Interoperability considerations: This is a grandfathered registration
which is only used in SCEP.
Published specification: draft-gutmann-scep-15
Applications that use this media type: SCEP uses this media type when
returning a Get Next CA Response.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): none
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the
Authors' Addresses section of draft-gutmann-scep-15
Intended usage: LIMITED USE
Restrictions on usage: SCEP protocol
Author: See the Authors' Addresses section of draft-gutmann-scep-15
Change controller: IETF
Provisional registration? no
7.4. Registration of application/x-pki-message media type
Type name: application
Subtype name: x-pki-message
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: This media type consists of a degenerate
certificates-only CMS Signed-Data message. There is no executable
content.
Interoperability considerations: This is a grandfathered registration
which is only used in SCEP.
Published specification: draft-gutmann-scep-15
Applications that use this media type: SCEP uses this media type when
returning a Certificate Enrolment/Renewal Response.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): none
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the
Authors' Addresses section of draft-gutmann-scep-15
Intended usage: LIMITED USE
Restrictions on usage: SCEP protocol
Author: See the Authors' Addresses section of draft-gutmann-scep-15
Change controller: IETF
Provisional registration? no
8. Security Considerations 8. Security Considerations
The security goal of SCEP is that no adversary can subvert the public The security goal of SCEP is that no adversary can subvert the public
key/identity binding from that intended. An adversary is any entity key/identity binding from that intended. An adversary is any entity
other than the client and the CA participating in the protocol. other than the client and the CA participating in the protocol.
This goal is met through the use of CMS and PKCS #10 encryption and This goal is met through the use of CMS and PKCS #10 encryption and
digital signatures using authenticated public keys. The CA's public digital signatures using authenticated public keys. The CA's public
key is authenticated via out-of-band means such as the checking of key is authenticated via out-of-band means such as the checking of
skipping to change at page 35, line 13 skipping to change at page 40, line 7
through manual or pre-shared secret authentication. through manual or pre-shared secret authentication.
8.1. General Security 8.1. General Security
Common key-management considerations such as keeping private keys Common key-management considerations such as keeping private keys
truly private and using adequate lengths for symmetric and asymmetric truly private and using adequate lengths for symmetric and asymmetric
keys must be followed in order to maintain the security of this keys must be followed in order to maintain the security of this
protocol. This is especially true for CA keys which, when protocol. This is especially true for CA keys which, when
compromised, compromise the security of all relying parties. compromised, compromise the security of all relying parties.
8.2. Use of the CA keypair 8.2. Use of the CA private key
A CA key pair is generally meant for, and is usually flagged as, A CA private key is generally meant for, and is usually flagged as,
being usable for certificate (and CRL) signing exclusively rather being usable for certificate (and CRL) signing exclusively rather
than data signing or encryption. The SCEP protocol however uses the than data signing or encryption. The SCEP protocol however uses the
CA private key to both sign and optionally encrypt CMS transport CA private key to both sign and optionally encrypt CMS transport
messages. This is generally considered undesirable as it widens the messages. This is generally considered undesirable as it widens the
possibility of an implementation weakness and provides an additional possibility of an implementation weakness and provides an additional
location where the private key must be used (and hence is slightly location where the private key must be used (and hence is slightly
more vulnerable to exposure) and where a side-channel attack might be more vulnerable to exposure) and where a side-channel attack might be
applied. applied.
8.3. Challenge Password 8.3. ChallengePassword Shared Secret Value
The challengePassword sent in the PKCS #10 enrolment request is The security measures that should be applied to the challengePassword
signed and encrypted by way of being encapsulated in a pkiMessage. shared secret depend on the manner in which SCEP is employed. In the
When saved by the CA, care should be taken to protect this password, simplest case, with SCEP used to provision devices with certificates
for example by storing a salted iterated hash of the password rather in the manufacturing facility, the physical security of the facility
than the password itself. may be enough to protect the certificate issue process with no
additional measures explicitly required. In general though the
security of the issue process depends on the security employed around
the use of the challengePassword shared secret. While it's not
possible to enumerate every situation in which SCEP may be utilised,
the following security measures should be considered.
o The challengePassword, despite its name, shouldn't be a
conventional password but a high-entropy shared secret
authentication string. Using the base64 encoding of a keying
value generated or exchanged as part of standard device
authentication protocols like EAP or DNP3 SA makes for a good
challengePassword. The use of high-entropy shared secrets is
particulary important when the PasswordRecipientInfo option is
used to encrypt SCEP messages, see Section 3.1.
o If feasible, the challengePassword should be a one-time value used
to authenticate the issue of a single certificate (subsequent
certificate requests will be authenticated by being signed with
the initial certificate). If the challengePassword is single-use
then the arrival of subsequent requests using the same
challengePassword can then be used to indicate a security breach.
o The lifetime of a challengePassword can be limited, so that it can
be used during initial device provisioning but will have expired
at a later date if an attacker manages to compromise the
challengePassword value, for example by compromising the device
that it's stored in.
o The CA should take appropriate measures to protect the
challengePassword, for example via physical security measures, or
by storing it as a salted iterated hash or equivalent memory-hard
function or as a keyed MAC value if it's not being used for
encryption, or by storing it in encrypted form if it is being used
for encryption.
8.4. Lack of Certificate Issue Confirmation 8.4. Lack of Certificate Issue Confirmation
SCEP provides no confirmation that the issued certificate was SCEP provides no confirmation that the issued certificate was
successfully received and processed by the client. This means that successfully received and processed by the client. This means that
if the CertRep message is lost or can't be processed by the client if the CertRep message is lost or can't be processed by the client
then the CA will consider the certificate successfully issued while then the CA will consider the certificate successfully issued while
the client won't. If this situation is of concern then the correct the client won't. If this situation is of concern then the correct
issuance of the certificate will need to be verified by out-of-band issuance of the certificate will need to be verified by out-of-band
means, for example through the client sending a message signed by the means, for example through the client sending a message signed by the
skipping to change at page 36, line 4 skipping to change at page 41, line 32
possession that's not present in the case of a renewal operation, see possession that's not present in the case of a renewal operation, see
Section 8.6. Section 8.6.
8.5. GetCACaps Issues 8.5. GetCACaps Issues
The GetCACaps response is not authenticated by the CA. This allows The GetCACaps response is not authenticated by the CA. This allows
an attacker to perform downgrade attacks on the cryptographic an attacker to perform downgrade attacks on the cryptographic
capabilities of the client/CA exchange. In particular if the server capabilities of the client/CA exchange. In particular if the server
were to support MD5 and single DES then an in-path attacker could were to support MD5 and single DES then an in-path attacker could
trivially roll back the encryption to use these insecure algorithms. trivially roll back the encryption to use these insecure algorithms.
By taking advantage of the presence of large amounts of static known By taking advantage of the presence of large amounts of static known
plaintext in the SCEP messages, as of 2017 a DES rainbow table attack plaintext in the SCEP messages, as of 2017 a DES rainbow table attack
can recover most encryption keys in under a minute, and MD5 chosen- can recover most encryption keys in under a minute, and MD5 chosen-
prefix collisions can be calculated for a few tens of cents of prefix collisions can be calculated for a few tens of cents of
computing time using tools like HashClash. computing time using tools like HashClash. It is for this reason
that this specification makes single DES and MD5 a MUST NOT feature.
Note that all known servers support at least triple DES and SHA-1
(regardless of whether "DES3" and "SHA-1" are indicated in
GetCACaps), so there should never be a reason to fall all the way
back to single DES and MD5. One simple countermeasure to a GetCACaps
downgrade attack is for clients that are operating in an environment
where on-path attacks are possible and that expect the "SCEPStandard"
capability to be indicated by the CA but don't see it in the
GetCACaps response to treat its absence as a security issue, and
either discontinue the exchange or continue as if "SCEPStandard" had
been returned. This requires a certain tradeoff between
compatibility with old servers and security against active attacks.
8.6. Lack of PoP in Renewal Requests 8.6. Lack of PoP in Renewal Requests
Renewal operations (but not standard certificate-issue operations) Renewal operations (but not standard certificate-issue operations)
are processed via a previously-issued certificate and its associated are processed via a previously-issued certificate and its associated
private key, not the key in the PKCS #10 request. This means that a private key, not the key in the PKCS #10 request. This means that a
client no longer demonstrates proof of possession (PoP) of the client no longer demonstrates proof of possession (PoP) of the
private key corresponding to the public key in the PKCS #10 request. private key corresponding to the public key in the PKCS #10 request.
It is therefore possible for a client to re-certify an existing key It is therefore possible for a client to re-certify an existing key
used by a third party, so that two or more certificates exist for the used by a third party, so that two or more certificates exist for the
same key. By switching out the certificate in a signature, an same key. By switching out the certificate in a signature, an
attacker can appear to have a piece of data signed by their attacker can appear to have a piece of data signed by their
certificate rather than the original signer's certificate. This, and certificate rather than the original signer's certificate. This, and
other, attacks are described in S/MIME ESS [15]. other, attacks are described in S/MIME ESS [21].
Avoiding these types of attacks requires situation-specific measures. Avoiding these types of attacks requires situation-specific measures.
For example CMS/SMIME implementations may use the ESSCertID attribute For example CMS/SMIME implementations may use the ESSCertID attribute
from S/MIME ESS [15] or its successor S/MIME ESSv2 [16] to from S/MIME ESS [21] or its successor S/MIME ESSv2 [22] to
unambiguously identify the signing certificate, however other unambiguously identify the signing certificate. However since other
mechanisms and protocols typically don't defend against this attack. mechanisms and protocols that the certificates will be used with
typically don't defend against this problem, it's unclear whether
this is an actual issue with SCEP.
8.7. Unnecessary cryptography 8.7. Traffic Monitoring
SCEP messages are signed with certificates that may contain
identifying information. If these are sent over the public Internet
and real identity information (rather than placeholder values or
arbitrary device IDs) are included in the signing certificate data,
an attacker may be able to monitor the identities of the entities
submitting the certificate requests. If this is an issue then [3]
should be consulted for guidance.
8.8. Unnecessary cryptography
Some of the SCEP exchanges use unnecessary signing and encryption Some of the SCEP exchanges use unnecessary signing and encryption
operations. In particular the GetCert and GetCRL exchanges are operations. In particular the GetCert and GetCRL exchanges are
encrypted and signed in both directions. The information requested encrypted and signed in both directions. The information requested
is public and thus encrypting the requests is of questionable value. is public and thus encrypting the requests is of questionable value.
In addition CRLs and certificates sent in responses are already In addition CRLs and certificates sent in responses are already
signed by the CA and can be verified by the recipient without signed by the CA and can be verified by the recipient without
requiring additional signing and encryption. More lightweight means requiring additional signing and encryption. More lightweight means
of retrieving certificates and CRLs such as HTTP certificate-store of retrieving certificates and CRLs such as HTTP certificate-store
access [11] and LDAP are recommended for this reason. access [17] and LDAP are recommended for this reason.
8.8. Use of SHA-1 8.9. Use of SHA-1
Virtually all of the large numbers of devices that use SCEP today The majority of the large numbers of devices that use SCEP today
default to SHA-1, with many supporting only that hash algorithm with default to SHA-1, with many supporting only that hash algorithm with
no ability to upgrade to a newer one. SHA-1 is no longer regarded as no ability to upgrade to a newer one. SHA-1 is no longer regarded as
secure in all situations, but as used in SCEP it's still safe. There secure in all situations, but as used in SCEP it's still safe. There
are three reasons for this. The first is that attacking SCEP would are three reasons for this. The first is that attacking SCEP would
require creating a SHA-1 collision in close to real time, which won't require creating a fully general SHA-1 collision in close to real
be feasible for a very long time. time alongside breaking AES (more specifically, it would require
creating a fully general SHA-1 collision for the PKCS #10 request,
breaking the AES encryption around the PKCS #10 request, and then
creating a second SHA-1 collision for the signature on the encrypted
data), which won't be feasible for a long time.
The second reason is that the signature over the message doesn't The second reason is that the signature over the message, in other
words the SHA-1 hash that isn't protected by encryption, doesn't
serve any critical cryptographic purpose: The PKCS #10 data itself is serve any critical cryptographic purpose: The PKCS #10 data itself is
authenticated through its own signature, protected by encryption, and authenticated through its own signature, protected by encryption, and
the overall request is authorised by the (encrypted) password. The the overall request is authorised by the (encrypted) shared secret.
sole exception to this will be the small number of implementations The sole exception to this will be the small number of
that support the Renewal operation, which may be authorised purely implementations that support the Renewal operation, which may be
through a signature, but presumably any implementation recent enough authorised purely through a signature, but presumably any
to support Renewal also supports SHA-2. Any legacy implementation implementation recent enough to support Renewal also supports SHA-2.
that supports the historic core SCEP protocol would not be affected. Any legacy implementation that supports the historic core SCEP
protocol would not be affected.
The third reason is that SCEP uses the same key for encryption and The third reason is that SCEP uses the same key for encryption and
signing, so that even if an attacker were able to capture an outgoing signing, so that even if an attacker were able to capture an outgoing
Renewal request that didn't include a password (in other words one Renewal request that didn't include a shared secret (in other words
that was only authorised through a signature), forge the SHA-1 hash one that was only authorised through a signature), break the AES
in real time, and forward the forged request to the CA, they couldn't encryption, forge the SHA-1 hash in real time, and forward the forged
decrypt the returned certificate, which is protected with the same request to the CA, they couldn't decrypt the returned certificate,
key that was used to generate the signature. While Section 8.7 which is protected with the same key that was used to generate the
points out that SCEP uses unnecessary cryptography in places, the signature. While Section 8.8 points out that SCEP uses unnecessary
additional level of security provided by the extra crypto makes it cryptography in places, the additional level of security provided by
immune to any issues with SHA-1. the extra crypto makes it immune to any issues with SHA-1.
This doesn't mean that SCEP implementations should continue to use This doesn't mean that SCEP implementations should continue to use
SHA-1 in perpetuity, merely that there's no need for a panicked SHA-1 in perpetuity, merely that there's no need for a panicked
switch to SHA-2. switch to SHA-2.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Josefsson, S., "The Base16, Base32, and Base64 Data [2] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", RFC 6838,
January 2013.
[3] Farrell, S. and H. Tschofenig, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 7258, May 2014.
[4] Leiba, B. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 8126, June 2017.
[5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[6] Crocker, R. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[7] Technology, U. N. I. O. S. A., "The Advanced Encryption
Standard (AES)", FIPS 197, November 2001.
[8] Technology, U. N. I. O. S. A., "Secure Hash Standard
(SHS)", FIPS 180-3, October 2008.
[9] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[3] Housley, R., "Cryptographic Message Syntax (CMS)", [10] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009. RFC 5652, September 2009.
[4] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [11] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[5] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [12] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
November 2000. November 2000.
[6] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [13] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
November 2000. November 2000.
[7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [14] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986, Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005. January 2005.
9.2. Informative References 9.2. Informative References
[9] Schaad, J. and M. Myers, "Certificate Management over CMS [16] Nottingham, M., "Building Protocols with HTTP", November
(CMC)", RFC 5272, June 2008. 2018.
[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 [17] Gutmann, P., "Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via HTTP", Operational Protocols: Certificate Store Access via HTTP",
RFC 4387, February 2006. RFC 4387, February 2006.
[12] "A Java implementation of the Simple Certificate Enrolment [18] "A Java implementation of the Simple Certificate Enrolment
Protocol", <https://github.com/jscep/jscep>. Protocol", <https://github.com/jscep/jscep>.
[13] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol", [19] Alighieri, D., "Internet Key Exchange (IKEv2) Protocol",
RFC 7296, March 1300. RFC 7296, March 1300.
[14] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [20] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[15] Hoffman, P., "Enhanced Security Services for S/MIME", [21] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[16] Schaad, J., "Enhanced Security Services (ESS) Update: [22] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, August 2007. Adding CertID Algorithm Agility", RFC 5035, August 2007.
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security [23] Rescorla, E., "The Transport Layer Security (TLS) Protocol
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Version 1.3", RFC 8446, August 2018.
Appendix A. Background Notes Appendix A. Background Notes
This specification has spent more than seventeen years in the draft This specification has spent over twenty years in the draft stage.
stage. Its original goal, provisioning IPsec routers with Its original goal, provisioning IPsec routers with certificates, has
certificates, has long since changed to general device/embedded long since changed to general device/embedded system/IoT use. To fit
system/IoT use. To fit this role, extra features were bolted on in a this role, extra features were bolted on in a haphazard manner
haphazard manner through the addition of a growing list of appendices through the addition of a growing list of appendices and by inserting
and by inserting additional, often conflicting, paragraphs in various additional, often conflicting, paragraphs in various locations in the
locations in the body text. Since existing features were never body text. Since existing features were never updated as newer ones
updated as newer ones were added, the specification accumulated large were added, the specification accumulated large amounts of historical
amounts of historical baggage over time. If OpenPGP was described as baggage over time. If OpenPGP was described as "a museum of 1990s
"a museum of 1990s crypto" then the SCEP draft was its graveyard. crypto" then the SCEP draft was its graveyard.
About five years ago the specification, which even at that point had About five years ago the specification, which even at that point had
seen only sporadic re-posts of the existing document, was more or seen only sporadic re-posts of the existing document, was more or
less abandoned by its original sponsors. Due to its widespread use less abandoned by its original sponsors. Due to its widespread use
in large segments of the industry, the specification was rebooted in in large segments of the industry, the specification was rebooted in
2015, cleaning up fifteen years worth of accumulated cruft, fixing 2015, cleaning up fifteen years worth of accumulated cruft, fixing
errors, clarifying ambiguities, and bringing the algorithms and errors, clarifying ambiguities, and bringing the algorithms and
standards used into the current century (prior to the update, the de- standards used into the current century (prior to the update, the de-
facto lowest-common denominator algorithms used for interoperability facto lowest-common denominator algorithms used for interoperability
were the insecure forty-year-old single DES and broken MD5 hash were the insecure forty-year-old single DES and broken MD5 hash
algorithms). algorithms).
Note that although the text of the current specification has changed Note that although the text of the current specification has changed
significantly due to the consolidation of features and appendices significantly due to the consolidation of features and appendices
into the main document, the protocol it describes is identical on the into the main document, the protocol that it describes is identical
wire to the original (with the exception of the switch from single on the wire to the original (with the unavoidable exception of the
DES and MD5 to AES and SHA-2). The only two changes introduced, the switch from single DES and MD5 to AES and SHA-2). The only two
"SCEPStandard" indicator in GetCACaps and the failInfoText attribute, changes introduced, the "SCEPStandard" indicator in GetCACaps and the
are both optional values and would be ignored by older failInfoText attribute, are both optional values and would be ignored
implementations that don't support them, or can be omitted from by older implementations that don't support them, or can be omitted
messages if they are found to cause problems. from messages if they are found to cause problems.
Other changes include: Other changes include:
o Resolved contradictions in the text, for example a requirement o Resolved contradictions in the text, for example a requirement
given as a MUST in one paragraph and a SHOULD in the next, a MUST given as a MUST in one paragraph and a SHOULD in the next, a MUST
NOT in one paragraph and a MAY a few paragraphs later, a SHOULD NOT in one paragraph and a MAY a few paragraphs later, a SHOULD
NOT contradicted later by a MAY, and so on. NOT contradicted later by a MAY, and so on.
o Merged several later fragmentary addenda placed in appendices (for o Merged several later fragmentary addenda placed in appendices (for
example the handling of certificate renewal) with the body of the example the handling of certificate renewal) with the body of the
text. text.
o Merged the SCEP Transactions and SCEP Transport sections, since o Merged the SCEP Transactions and SCEP Transport sections, since
the latter mostly duplicated (with occasional inconsistencies) the the latter mostly duplicated (with occasional inconsistencies) the
former. former.
o Updated the algorithms to ones dating from at least this century. o Updated the algorithms to ones dating from at least this century.
o Did the same for normative references to other standards. o Did the same for normative references to other standards.
o Updated the text to use consistent terminology for the client and o Updated the text to use consistent terminology for the client and
CA rather than a mixture of client, requester, end entity, server, CA rather than a mixture of client, requester, requesting system,
certificate authority, certification authority, and CA. end entity, server, certificate authority, certification
authority, and CA.
o Corrected incorrect references to other standards, e.g. o Corrected incorrect references to other standards, e.g.
IssuerAndSerial -> IssuerAndSerialNumber. IssuerAndSerial -> IssuerAndSerialNumber.
o Corrected errors such as a statement that when both signature and o Corrected errors such as a statement that when both signature and
encryption certificates existed, the signature certificate was encryption certificates existed, the signature certificate was
used for encryption. used for encryption.
o Condensed redundant discussions of the same topic spread across o Condensed redundant discussions of the same topic spread across
multiple sections into a single location. For example the multiple sections into a single location. For example the
description of intermediate CA handling previously existed in description of intermediate CA handling previously existed in
three different locations, with slightly different reqirements in three different locations, with slightly different reqirements in
each one. each one.
o Added a description of how pkiMessages were processed, which was o Added a description of how pkiMessages were processed, which was
never made explicit in the original specification. This led to never made explicit in the original specification. This led to
skipping to change at page 41, line 4 skipping to change at page 47, line 40
how it was used. It's unclear whether what was meant was a true how it was used. It's unclear whether what was meant was a true
RA or merely an intermediate CA, as opposed to the default RA or merely an intermediate CA, as opposed to the default
practice of having certificates issued directly from a single root practice of having certificates issued directly from a single root
CA certificate. This update uses the term "intermediate CA CA certificate. This update uses the term "intermediate CA
certificates", since this seems to have been the original intent certificates", since this seems to have been the original intent
of the text. of the text.
o Redid the PKIMessage diagram to match what was specified in CMS, o Redid the PKIMessage diagram to match what was specified in CMS,
the original diagram omitted a number of fields and nested data the original diagram omitted a number of fields and nested data
structures which meant that the diagram didn't match either the structures which meant that the diagram didn't match either the
text or the CMS specification. text or the CMS specification.
o Removed the requirement for a CertPoll to contain a o Removed the requirement for a CertPoll to contain a
recipientNonce, since CertPoll is a client message and will never recipientNonce, since CertPoll is a client message and will never
be sent in response to a message containing a senderNonce. See be sent in response to a message containing a senderNonce. See
also the note in Section 3.3.2. also the note in Section 3.3.2.
o Clarified certificate renewal. These represent a capability that o Clarified certificate renewal. This represents a capability that
was bolted onto the original protocol with (at best) vaguely- was bolted onto the original protocol with (at best) vaguely-
defined semantics, including a requirement by the CA to guess defined semantics, including a requirement by the CA to guess
whether a particular request was a renewal or not. In response to whether a particular request was a renewal or not. In response to
developer feedback that they either avoided renewal entirely developer feedback that they either avoided renewal entirely
because of this uncertainty or hardcoded in particular behaviour because of this uncertainty or hardcoded in particular behaviour
on a per-CA basis, this specification explicitly identifies on a per-CA basis, this specification explicitly identifies
renewal requests as such, and provides proper semantics for them. renewal requests as such, and provides proper semantics for them.
o Corrected the requirement that "undefined message types are
treated as an error" since this negates the effect of GetCACaps,
which is used to define new message types. In particular
operations such as GetCACaps "Renewal" would be impossible if
enforced as written, because the Renewal operation was an
undefined message type at the time.
o In line with the above, added IANA registries for several entries
that had previously been defined in an ad-hoc manner in different
locations in the text.
o Added the "SCEPStandard" keyword to GetCACaps to indicate that the o Added the "SCEPStandard" keyword to GetCACaps to indicate that the
CA complies with the final version of the SCEP standard, since the CA complies with the final version of the SCEP standard, since the
definition of what constitutes SCEP standards compliance has definition of what constitutes SCEP standards compliance has
changed significantly over the years. changed significantly over the years.
o Added the optional failInfoText attribute to deal with the fact o Added the optional failInfoText attribute to deal with the fact
that failInfo was incapable of adequately communicating to clients that failInfo was incapable of adequately communicating to clients
why a certificate request operation had been rejected. why a certificate request operation had been rejected.
o Removed the discussion in the security considerations of o Removed the discussion in the security considerations of
revocation issues, since SCEP doesn't support revocation as part revocation issues, since SCEP doesn't support revocation as part
of the protocol. of the protocol.
 End of changes. 158 change blocks. 
433 lines changed or deleted 747 lines changed or added

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