Internet Engineering Task Force A. Nourse
Internet-Draft Cisco Systems, Inc
Intended status: Historic J. Vilhuber, Ed.
Expires: October 3, 2009 Cisco Systems, Inc.
April 2009
Cisco Systems' Simple Certificate Enrollment Protocol
draft-nourse-scep-19
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies the Simple Certificate Enrollment Protocol, a
PKI communication protocol which leverages existing technology by
Nourse & Vilhuber Expires October 3, 2009 [Page 1]
Internet-Draft SCEP April 2009
using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the
enrollment protocol developed by VeriSign, Inc. for Cisco Systems,
Inc. It now enjoys wide support in both client and CA
implementations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. SCEP Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.1. Requester Initialization . . . . . . . . . . . . . 6
2.1.1.2. Trusted CA Store . . . . . . . . . . . . . . . . . 7
2.1.2. Certification Authority . . . . . . . . . . . . . . . 7
2.1.2.1. CA Certificate Fingerprint . . . . . . . . . . . . 8
2.1.2.2. Certification Authority Policies . . . . . . . . . 8
2.1.2.3. CRL's and CDP's . . . . . . . . . . . . . . . . . 8
2.1.2.4. Name Uniqueness . . . . . . . . . . . . . . . . . 8
2.1.2.5. Retransmission versus new request . . . . . . . . 8
2.1.2.6. Requester authentication . . . . . . . . . . . . . 9
2.1.3. Registration Authority . . . . . . . . . . . . . . . . 11
2.2. SCEP Functionality . . . . . . . . . . . . . . . . . . . . 11
2.2.1. CA/RA Certificate Distribution . . . . . . . . . . . . 11
2.2.2. Certificate Enrollment . . . . . . . . . . . . . . . . 12
2.2.2.1. State Transitions in Certificate Enrollment . . . 12
2.2.3. Certificate Access . . . . . . . . . . . . . . . . . . 14
2.2.4. CRL Access . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5. Certificate Revocation . . . . . . . . . . . . . . . . 16
2.3. PKI Operation Transactional Behavior . . . . . . . . . . . 16
2.3.1. Transaction Identifier . . . . . . . . . . . . . . . . 16
2.3.2. Transaction Behavior of Certificate/CRL Access . . . . 16
2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 18
3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 20
3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 20
3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 20
3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 21
3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . . 21
3.1.1.5. senderNonce and responderNonce . . . . . . . . . . 21
3.1.1.6. signingTime Attribute . . . . . . . . . . . . . . 22
3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 22
3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 22
3.2.1. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 24
Nourse & Vilhuber Expires October 3, 2009 [Page 2]
Internet-Draft SCEP April 2009
3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 24
3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 24
3.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 25
3.2.3.1. IssuerAndSubject . . . . . . . . . . . . . . . . . 25
3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Degenerate certificates-only PKCS#7 Signed-data . . . . . 26
4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . . 27
4.1.1. Get CA Certificate Response Message Format . . . . . . 27
4.1.1.1. CA Certificate Response Message Format . . . . . . 27
4.1.1.2. CA/RA Certificate Response Message Format . . . . 27
4.2. Certificate Enrollment . . . . . . . . . . . . . . . . . . 27
4.2.1. Certificate Enrollment Response Message . . . . . . . 28
4.3. Poll for Requester Initial Certificate . . . . . . . . . . 28
4.3.1. Polling Response Message Format . . . . . . . . . . . 29
4.4. Certificate Access . . . . . . . . . . . . . . . . . . . . 29
4.4.1. Certificate Access Response Message Format . . . . . . 29
4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5.1. CRL Access Response Message Format . . . . . . . . . . 30
4.6. Get Next Certification Authority Certificate . . . . . . . 30
4.6.1. Get Next CA Response Message Format . . . . . . . . . 30
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 31
5.1. HTTP "GET" Message Format . . . . . . . . . . . . . . . . 31
5.1.1. Response Message Format . . . . . . . . . . . . . . . 31
5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . . 32
5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . . 32
5.2.2. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.2.1. PKCSReq Response . . . . . . . . . . . . . . . . . 33
5.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 33
5.2.3.1. GetCertInitial Response . . . . . . . . . . . . . 33
5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . . 33
5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 34
5.2.6. GetNextCaCert . . . . . . . . . . . . . . . . . . . . 34
5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . . 34
6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8.1. General Security . . . . . . . . . . . . . . . . . . . . . 35
8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 35
8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 35
8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 36
8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 36
8.6. Key Usage Issues . . . . . . . . . . . . . . . . . . . . . 36
8.7. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 36
Nourse & Vilhuber Expires October 3, 2009 [Page 3]
Internet-Draft SCEP April 2009
8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . . 37
8.9. GetNextCaCert . . . . . . . . . . . . . . . . . . . . . . 37
9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 37
10. Normative References . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. IPSEC Client Enrollment Certificate Request . . . . . 38
Appendix B. Private OID Definitions . . . . . . . . . . . . . . . 40
Appendix C. SCEP State Transitions . . . . . . . . . . . . . . . 40
Appendix D. CA Capabilities . . . . . . . . . . . . . . . . . . . 43
D.1. GetCACaps HTTP Message Format . . . . . . . . . . . . . . 43
D.2. CA Capabilities Response Format . . . . . . . . . . . . . 43
Appendix E. Certificate Renewal and CA Key Rollover . . . . . . . 44
Appendix F. PKIOperation via HTTP POST Message . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Nourse & Vilhuber Expires October 3, 2009 [Page 4]
Internet-Draft SCEP April 2009
1. Introduction
Public key technology is widely available and increasingly widely
deployed. X.509 certificates serve as the basis for several
standards-based security protocols in the IETF, such as IKE [RFC2409]
and IKEv2 [RFC4306], and TLS [RFC4346]. When an X.509 certificate is
issued by other than the certificate subject (a self-issued
certificate), there typically is a need for a certificate management
protocol. Such a protocol enables a PKI client to request a
certificate, certificate renewal, or certificate revocation from a
certification authority. Often there also is a need for protocols to
request a certificate or certificate status information, although
these functions are often provided by distinct protocols.
This specification defines a protocol, SCEP, for certificate
management and certificate and CRL queries in a closed environment.
While widely deployed, this protocol omits some certificate
management features, e.g., in-band certificate revocation
transactions, that can significantly enhance the security achieved in
a PKI. The IETF protocol suite currently includes two certificate
management protocols with more comprehensive functionality: CMP
[RFC4210] and Certificate Management over CMS [RFC5272]. Where
interoperability with the installed base of SCEP implementations is
required, implementers are encouraged to support a comprehensive
standards track certificate management protocol in addition to the
protocol defined in this specification. This implementation strategy
balances near term requirements for interoperability with longer term
security goals.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. SCEP Protocol Overview
The goal of SCEP is to support the secure issuance of certificates to
network devices in a scalable manner, using existing technology
whenever possible. The protocol supports the following operations:
o CA and RA public key distribution
o Certificate enrollment
o Certificate query
Nourse & Vilhuber Expires October 3, 2009 [Page 5]
Internet-Draft SCEP April 2009
o CRL query
SCEP makes extensive use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986].
2.1. SCEP Entities
The entity types defined in SCEP are
o the requester (Section 2.1.1) (e.g., IPSEC clients)
o the certification authority (Section 2.1.2) (CA)
o the Registration Authority (Section 2.1.3) (RA)
A requester is sometimes called a "SCEP client" in this document.
2.1.1. Requester
A requester is an entity whose name is defined in a certificate
subject field and optionally, in subjectAltName, a X.509 v3
certificate extension.
Certificate requests for certificates whose purpose is a specific
solution are encouraged to conform to the solution's profile, e.g.
[RFC4945] section 5 for IKE/IPsec certificates.
2.1.1.1. Requester Initialization
The requester initialization includes the key pair generation and the
configuring of the required information to communicate with the
certification authority.
A requester MUST generate, and provide storage for, asymmetric key
pairs. If the requester does not have enough permanent memory to
save its certificate, then it should be able to query its own
certificate from the CA or an LDAP server, once the certificate has
been issued (see Section 3.2.3).
2.1.1.1.1. RSA Key Pairs
Before a requester can start a PKI transaction, it MUST have at least
one RSA key pair.
Key pairs may be intended for particular purposes, such as encryption
only or signing only. The usage of any associated certificate can be
restricted by adding key usage and extended key usage attributes to
the PKCS#10 [RFC2986]. If key usage is not present, the public key
is assumed to be a general purpose key that may be used for all
Nourse & Vilhuber Expires October 3, 2009 [Page 6]
Internet-Draft SCEP April 2009
purposes.
2.1.1.1.2. non-RSA Keys
SCEP does not support non-RSA keys. Though the protocol (being based
on PKCS#7 [RFC2315]) does not preclude them, RSA is the only
algorithm supported by current implementations.
2.1.1.1.3. Required Information
A requester MUST have the following information configured before
starting any PKI operations:
1. the certification authority IP address or fully qualified domain
name,
2. the certification authority HTTP CGI script path,
3. the HTTP proxy information if there is no direct Internet
connection to the server,
4. If CRLs are being published by the CA to an LDAP directory
server, and there is a CRL Distribution Point containing only an
X.500 directory name, then the client will need to know the LDAP
server fully qualified domain name or IP address. CRL
Distribution Points are discussed in more detail in [RFC5280].
2.1.1.2. Trusted CA Store
To support interoperability between IPSEC peers whose certificates
are issued by different CAs, SCEP allows the users to configure
multiple trusted certificates. Trusted certificates are configured
as such in the client, based on some out-of-band means such as a
"fingerprint". These trusted certificates are used to verify
certificate chains that end in those certificates.
2.1.2. Certification Authority
A certification authority (CA) is an entity whose name appears in the
issuer field of a certificate.
Before any PKI operations can occur, the CA generates its own public
key pair and creates a self-signed CA certificate, or causes another
CA to issue a certificate to it.
CA key-rollover and certificate expiry is address in Appendix E.
Nourse & Vilhuber Expires October 3, 2009 [Page 7]
Internet-Draft SCEP April 2009
2.1.2.1. CA Certificate Fingerprint
If a CA certificate is self-signed and not pre-provisioned on the
client, a CA Certificate fingerprint will be used to authenticate the
received CA Certificate.
The fingerprint is created by calculating a SHA-1, SHA-256, SHA-512,
or MD5 hash on the whole CA certificate. Before any requester can
start its enrollment, this CA certificate has to be configured at the
entity side securely.
2.1.2.2. Certification Authority Policies
A certification authority may enforce any arbitrary policies,
including name policies, and apply them to the request, possibly
causing the request to be rejected. The requester MUST NOT assume
any of the fields, except for the public key, will be the same in the
resulting certificate as in the request.
2.1.2.3. CRL's and CDP's
The certification authority MUST either include a
cRLDistributionPoint extension in every certificate it issues or
answer CRL queries itself, in which case it MUST be online all the
time. The certification authority SHOULD also either answer
certificate queries or make certificates available via LDAP.
2.1.2.4. Name Uniqueness
A CA MAY enforce the property that there be only one key pair for a
given subject name and key usage combination at any given time. This
property is called the certificate name uniqueness property.
2.1.2.5. Retransmission versus new request
It is desirable that the CA enforce certificate-name uniqueness, but
it is not mandatory. A CA that does not enforce uniqueness must
provide some other mechanism to prevent the re-transmission of an
enrollment request by a SCEP client from creating a second
certificate. Nor can the second request merely be rejected.
If a client times out from polling for a pending request it can
resynchronize by reissuing the original request with the original
subject name, key, and transaction ID. This should return the status
of the original transaction, including the certificate, if it was
granted. It should not create a new transaction unless the original
certificate has been revoked, or the transaction arrives more than
halfway through the validity period of the original certificate.
Nourse & Vilhuber Expires October 3, 2009 [Page 8]
Internet-Draft SCEP April 2009
An enrollment request that occurs more than halfway through the
validity period of an existing certificate for the same subject name
and key usage MAY be interpreted as a re-enrollment or renewal
request and be accepted. A new certificate with new validity dates
may be issued, even though the old one is still valid, if the CA
policy permits, as described in Section 2.1.2.6.3. See also
Appendix E.
2.1.2.6. Requester authentication
As with every protocol that uses public-key cryptography, the
association between the public keys used in the protocol and the
identities with which they are associated must be authenticated in a
cryptographically secure manner. This requirement is needed to
prevent a "man-in-the-middle" attack, in which an adversary can
manipulate the data as it travels between the protocol participants
and subvert the security of the protocol.
PKCS#10 [RFC2986] specifies the use of a PKCS#9 [RFC2985]
challengePassword attribute to be sent as part of the enrollment
request. SCEP uses this challengePassword to satisfy the above
requirements for security. The PKCS#7 [RFC2315] envelope protects
the privacy of the challenge password.
2.1.2.6.1. Manual enrollment authentication
In the manual mode, the requester is required to wait until its
identity can be verified by the CA operator using any reliable out-
of-band method. To prevent a "man-in-the-middle" attack, a SHA-1,
SHA-256, SHA-512, or MD5 'fingerprint' generated on the PKCS#10
[RFC2986] (before PKCS#7 [RFC2315] enveloping and signing) SHOULD be
compared out-of-band between the CA operator and the requester. SCEP
clients and CAs (or RAs, if appropriate) MUST display this
fingerprint to the operator to enable this verification if manual
mode is used. Failing to provide this information leaves the
protocol vulnerable to attack by sophisticated adversaries.
In this case the challenge password is only used to authenticate a
request for the certificate's revocation.
2.1.2.6.2. Automated enrollment authentication
When utilizing a pre-shared secret scheme, the server MAY distribute
a shared secret to the requester, which will uniquely associate the
enrollment request with the requester. The distribution of the
secret must be private: only the end entity should know this secret.
The actual binding mechanism between the requester and the secret is
subject to the server policy and implementation.
Nourse & Vilhuber Expires October 3, 2009 [Page 9]
Internet-Draft SCEP April 2009
When using the pre-shared secret scheme, the requester MUST enter the
pre-distributed secret as the challengePassword.
The pre-shared secret MAY also be used to authenticate a request for
the certificate's revocation.
2.1.2.6.3. Existing CA-Issued or Self-Signed Certificates
In this protocol, the communication between the requester and the
certification authority is secured by using PKCS#7 [RFC2315] as the
messaging protocol (see Section 3). PKCS#7 [RFC2315], however, is a
data format which assumes the communicating entities already possess
the peer's certificates and requires that both parties use the
subject names and issuer assigned certificate serial numbers to
identify the certificate in order to verify the signature and decrypt
the message.
o If the requesting system already has a certificate issued by the
CA, and the CA supports RENEWAL (see Appendix D), that certificate
SHOULD be presented as credentials for the renewal of that
certificate if the CA supports the "Renewal" capability and the CA
policy permits the certificate to be renewed.
o If the requesting system has no certificate issued by the CA, but
has credentials from a different CA, and the CA supports RENEWAL
(see Appendix D), that certificate MAY be presented as credentials
instead of a self-signed certificate. Policy settings on the CA
will determine if the request can be accepted or not. This is
useful when enrolling with a new administrative domain, using a
certificate from the old domain as credentials.
o If the requester does not have an appropriate existing
certificate, then a self-signed certificate MUST be used instead.
The self-signed certificate MUST use the same subject name as in
the PKCS#10 request.
During the certificate enrollment, the requester MUST use the
appropriate certificate to sign the PKCS#7 [RFC2315] (see Section 3).
When the certification authority creates the PKCS#7 [RFC2315]
envelope on the issued certificate, it SHOULD use the public key,
issuer name, and serial number conveyed in the above included
certificate. This will inform the end entity of which private key
should be used to open the envelope.
Note that when a client enrolls for separate encryption and signature
certificates, it may use the signature certificate to sign both
requests, and then expect its signature key to be used to encrypt
Nourse & Vilhuber Expires October 3, 2009 [Page 10]
Internet-Draft SCEP April 2009
both responses.
In any case, the RecipientInfo on the envelope MUST reflect the key
used to encrypt the request.
2.1.3. Registration Authority
In an environment where a Registration Authority (RA) is present, a
requester performs enrollment through the RA. In order to securely
communicate with an RA using PKCS#7 [RFC2315], the client MUST use
the RA's keys instead of the CA's keys. The RA certificate(s) (in
addition to the CA certificate) will be returned in the GetCaCert
Response (see Section 5.2.1.1.2) automatically.
Clients MUST verify the authorization of the RA certificates. The
authorization mechanism is specified by the CA administrator and is
out of scope for this document.
In the following, the CA and RA are specified as one entity in the
context of PKI operation definitions.
2.2. SCEP Functionality
In this section, we give a high level overview of the functionality
of SCEP.
2.2.1. CA/RA Certificate Distribution
If the CA and/or RA certificates have not previously been acquired by
the requester in some other means, the requester MUST retrieve the
CA/RA certificates before any PKI operation (Section 3) can be
started.
Since no public key has yet been exchanged between the requester and
the CA/RA, the messages cannot be secured using PKCS#7 [RFC2315], and
the data is instead transferred in the clear.
If an RA is in use, a certificates-only PKCS#7 [RFC2315] SignedData
with a certificate chain consisting of both RA and CA certificates is
returned. Otherwise the CA certificate itself is returned. The
transport protocol (Section 5) MUST indicate which one is returned.
After the requester gets the CA certificate, it MUST authenticate the
CA certificate by comparing the CA certificate fingerprint (see
Section 2.1.2.1) with the CA/RA operator out-of-band. Since the RA
certificates (if any) are signed by the CA, there is no need to
authenticate the RA certificates.
Nourse & Vilhuber Expires October 3, 2009 [Page 11]
Internet-Draft SCEP April 2009
Because a long time can pass between queries from a requester to a
CA/RA and because RA certificates can change at any time, it is
recommended that a requester not store RA certificates. Instead, the
requester SHOULD retrieve the CA/RA certificates before each
operation.
2.2.2. Certificate Enrollment
A requester starts an enrollment (Section 3.2.1) transaction by
creating a certificate request using PKCS#10 [RFC2986] and sends it
to the CA/RA enveloped using the PKCS#7 (Section 3).
It is up to local CA policy (and CA implementation) as to whether a
certificate is granted automatically, or whether it is manually
granted by the administrator. The challengePassword MAY be used to
automatically authenticate the request.
If the CA/RA returns a CertRep (Section 3.2.2) message with status
set to PENDING, the requester enters into polling mode by
periodically sending a GetCertInitial (Section 3.2.3) PKI message to
the CA/RA, until the CA/RA operator completes the manual
authentication (approving or denying the request).
In general, the requester will send a single PKCSReq (Section 3.2.1)
message, followed by 0 or more GetCertInitial (Section 3.2.3)
messages, if polling mode is entered.
In general, the CA/RA will send 0 or more CertRep (Section 3.2.2)
messages with status set to PENDING, followed by a single CertRep
(Section 3.2.2) with status set to either SUCCESS or FAILURE.
2.2.2.1. State Transitions in Certificate Enrollment
The requester state transitions during enrollment operation are
indicated in Figure 1.
Nourse & Vilhuber Expires October 3, 2009 [Page 12]
Internet-Draft SCEP April 2009
GetCertInitial
+----<---+
| | CertRep(PENDING),
| | GetCertInitial send-timeout,
| | new-poll timer
| |
[CERT-NONEXISTANT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED]
^ PKCSReq | | ^
| | | |
| | +---------------+
| | CertRep(SUCCESS)
+--------------------------+
CertRep(FAILURE),
PKCSReq send-timeout,
max-time/max-polls exceeded
Figure 1: State Transition Diagram
Certificate enrollment starts at the state CERT-NONEXISTANT.
Sending a PKCSReq message changes the state to CERT-REQ-PENDING. If
there is no response, or sending is not possible, the state reverts
back to CERT-NONEXISTANT.
Receiving a CertRep message with pkiStatus set to SUCCESS changes the
state to CERT-ISSUED.
Receiving a CertRep message with pkiStatus set to FAILURE changes the
state to CERT-NONEXISTANT.
If the server sends back a CertRep message with pkiStatus set to
PENDING, the requester will keep polling by sending a GetCertInitial
message to the server, until either a CertRep message with status set
to SUCCESS is received, or the maximum number of polls has been
exceeded.
If the maximum number of polls has been exceeded or a CertRep message
with pkiStatus set to FAILURE is received while in the CERT-REQ-
PENDING state, the end entity will transition to the CERT-NONEXISTANT
state, and the SCEP client can eventually initiate another enrollment
request. It is important to note that, as long as the requester does
not change its subject name or keys, the same transaction ID will be
used in the "new" transaction. This is important because based on
this transaction ID, the certification authority can recognize this
as an existing transaction instead of a new one.
Nourse & Vilhuber Expires October 3, 2009 [Page 13]
Internet-Draft SCEP April 2009
A successful transaction in automatic mode:
REQUESTER CA SERVER
PKCSReq: PKI cert. enrollment msg
--------------------------------> CertRep: pkiStatus = SUCCESS
certificate attached
<------------------------------
Receive issued certificate.
Figure 2: Automatic mode transaction
A successful transaction in manual mode:
REQUESTER CA SERVER
PKCSReq: PKI cert. enrollment msg
--------------------------------> CertRep: pkiStatus = PENDING
<------------------------------
GetCertInitial: polling msg
--------------------------------> CertRep: pkiStatus = PENDING
<------------------------------
................ <manual identity authentication>...............
GetCertInitial: polling msg
--------------------------------> CertRep: pkiStatus = SUCCESS
certificate attached
<------------------------------
Receive issued certificate.
Figure 3: Manual mode transaction
2.2.3. Certificate Access
There are two methods to query certificates. The first method is to
use LDAP as a query protocol. Using LDAP to query assumes the client
understands the LDAP scheme supported by the CA. The SCEP client
assumes that the subject DN in the certificate is used as the URL to
query the certificate. The standard attributes (userCertificate and
caCertificate) are used as filter.
For the environment where LDAP is not available, a certificate query
message is defined to retrieve the certificates from the CA.
To query a certificate from the certification authority, a requester
sends a request consisting of the certificate's issuer name and
serial number. This assumes that the requester has saved the issuer
name and the serial number of the issued certificate from the
previous enrollment transaction. The transaction to query a
certificate consists of one GetCert (Section 3.2.4) message and one
CertRep (Section 3.2.2) message, as shown in Figure 4.
Nourse & Vilhuber Expires October 3, 2009 [Page 14]
Internet-Draft SCEP April 2009
REQUESTER CA SERVER
GetCert: PKI certificate query msg
-------------------------------> CertRep: pkiStatus = SUCCESS
certificate attached
<-----------------------------
Receive the certificate.
Figure 4: GetCert Transaction
2.2.4. CRL Access
The CA/RA will not "push" the CRL to the end entities. The query of
the CRL can only be initialized by the requester.
There are two methods to retrieve a CRL:
1. If the CA supports CRL Distribution Points [RFC5280] (section
4.2.1.13), then the CRL MUST be retrieved via the mechanism
specified in the CDP.
2. If the CA does not support CDP's, a CRL query is composed by
creating a message consisting of the subject name and serial
number of the certification authority's certificate. This method
is deprecated because
* it does not scale well
* requires the CA to be a high-availability service
* does not provide sufficient information to determine the CRL
scope (see [RFC5280] Section 5) other than "all certificates
by this CA".
The message is sent to the CA in the same way as the other SCEP
requests: The transaction to retrieve a CRL consists of one GetCRL
PKI message and one CertRep PKI message, which contains only the CRL
(no certificates), as shown in Figure 5.
REQUESTER CA SERVER
GetCRL: PKI CRL query msg
---------------------------------->
CertRep: CRL attached
<--------------------------------
Figure 5: GetCRL Transaction
Nourse & Vilhuber Expires October 3, 2009 [Page 15]
Internet-Draft SCEP April 2009
2.2.5. Certificate Revocation
SCEP currently only allows revocation as an out-of-band process.
In order to revoke a certificate, the requester must contact the CA
server operator, who MAY wish to verify the challenge password (which
has been sent to the server as an attribute of the PKCS#10 [RFC2986]
certificate request). If the challenge password matches, the
certificate can be revoked.
2.3. PKI Operation Transactional Behavior
As described before, a PKI operation is a transaction consisting of
the messages exchanged between a requester and the CA/RA. This
section will specify the transaction behavior on both the requester
and the certification authority server. Because the protocol is
basically a two way communication protocol without a confirmation
message from the initiating side, state and state resynchronization
rules have to be defined, in case any error happens at either side.
Before the state transition can be defined, the notion of transaction
identifier has to be defined first.
2.3.1. Transaction Identifier
A transaction identifier is a string generated by the entity when
starting a transaction. Since all the PKI operations defined in this
protocol are initiated by the requester, it is the responsibility of
the requester to generate a unique string as the transaction
identifier. All the PKI messages exchanged for a given PKI
transaction must carry the same transaction identifier.
The transaction identifier is generated as a SHA-1, SHA-256, SHA-512
or MD5 hash on the public key value for which the enrollment request
is made. This allows the SCEP client to reuse the same transaction
identifier if it is reissuing a request for the same certificate
(i.e. a certificate with the same subject, issuer, and key). The
SCEP protocol requires that transaction identifiers be unique, so
that queries can be matched up with transactions. For this reason,
in those cases in which separate signing and encryption certificates
are issued to the same requester, the keys must be different.
2.3.2. Transaction Behavior of Certificate/CRL Access
There is no state maintained during certificate access and CRL access
transaction. When using the certificate query and CRL query messages
defined in this protocol, the transaction identifier is still
required so that the requester can match the response message with
the outstanding request message. When using LDAP to query the
Nourse & Vilhuber Expires October 3, 2009 [Page 16]
Internet-Draft SCEP April 2009
certificate and the CRL, the behavior is specified by the LDAP
protocol.
2.4. Security
The security goals of SCEP are that no adversary can:
o subvert the public key/identity binding from that intended,
o discover the identity information in the enrollment requests and
issued certificates,
o cause the revocation of certificates with any non-negligible
probability.
Here an adversary is any entity other than the requester and the CA
(and optionally the RA) participating in the protocol that is
computationally limited, but that can manipulate data during
transmission (that is, a man-in-the-middle). The precise meaning of
'computationally limited' depends on the implementer's choice of
cryptographic hash functions and ciphers. The required algorithms
are RSA, DES and MD5. Depending on the CA capabilities (see
Appendix D), Triple-DES MAY be used instead of DES, and SHA-1, SHA-
256, or SHA-512 MAY be used instead of MD5.
The first and second goals are met through the use of PKCS#7
[RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures
using authenticated public keys. The CA's public key is
authenticated via the checking of the CA fingerprint, as specified in
Section 2.1.2, and the SCEP client's public key is authenticated
through the manual authentication or pre-shared secret
authentication, as specified in Section 2.1.2.6. The third goal is
met through the use of a challenge password for revocation, which is
chosen by the SCEP client and communicated to the CA protected by the
PKCS#7 [RFC2315] encryptedData, as specified in Section 2.2.5.
The motivation of the first security goal is straightforward. The
motivation for the second security goal is to protect the identity
information in the enrollment requests and certificates. For
example, two IPSEC hosts behind a firewall may need to exchange
certificates, and may need to enroll certificates with a CA that is
outside of a firewall.
Most networks with firewalls seek to prevent IP addresses and DNS
information from the trusted network leaving that network. The
second goal enables the hosts in this example to enroll with a CA
outside the firewall without revealing this information. The
motivation for the third security goal is to protect the SCEP clients
Nourse & Vilhuber Expires October 3, 2009 [Page 17]
Internet-Draft SCEP April 2009
from denial of service attacks.
3. SCEP Secure Message Objects
PKCS#7 [RFC2315] is a general enveloping mechanism that enables both
signed and encrypted transmission of arbitrary data.
All messages MUST be valid PKCS#7 [RFC2315] structures, unless
otherwise noted.
SCEP messages that require confidentiality use two layers of PKCS#7,
as shown in Figure 6. By applying both enveloping and signing
transformations, the SCEP message is protected both for the integrity
of its end-to-end transaction information and the confidentiality of
its information portion. The advantage of this technique over the
conventional transaction message format is that the signed
transaction type information and the status of the transaction can be
determined prior to invoking security handling procedures specific to
the information portion being processed.
Some messages do not require enveloping, in which case the
EnvelopedData in Figure 6 is omitted.
ContentType = SignedData (called pkiMessage)
SignerInfo
Signature
authenticatedAttributes
transactionID
messageType
pkiStatus
failInfo
senderNonce
recipientNonce
etc
ContentInfo type = EnvelopedData (called pkcsPKIEnvelope; optional)
RecipientInfo
ContentInfo type = Data
messageData
Figure 6: PKCS#7 Layering
Description:
o The outer PKCS#7 is a pkiMessage (Section 3.1).
o The SignedData ContentInfo, if present (e.g. FAILURE and PENDING
CertRep messages will lack any signed content), MUST be a
Nourse & Vilhuber Expires October 3, 2009 [Page 18]
Internet-Draft SCEP April 2009
pkcsPKIEnvelope (Section 3.1.2).
When a particular SCEP message carries data, this data is carried in
the messageData.
Note: The remainder of this document will refer only to
'messageData', but it is understood to always be encapsulated in the
pkcsPKIEnvelope (Section 3.1.2). The format of the data in the
messageData is defined by the messageType attribute (see
Section 3.1.1) of the SignedData. If there is no messageData to be
transmitted, the entire pkcsPKIEnvelope MUST be omitted.
3.1. SCEP pkiMessage
The basic building block of all secured SCEP messages is the SCEP
pkiMessage. It consists of an PKCS#7 signed-data content type, as
defined in PKCS#7 [RFC2315] Section 9. The following restrictions
apply:
o version MUST be 1
o the contentType in contentInfo MUST be data ({pkcs-7 1}) as
defined in PKCS#7 [RFC2315] Section 8.
o The signed content, if present (e.g. FAILURE and PENDING CertRep
messages will lack any signed content), MUST be a pkcsPKIEnvelope
(Section 3.1.2), and must match the messageType attribute.
o The SignerInfo MUST contain a set of authenticatedAttributes (see
PKCS#7 [RFC2315] Section 9.2 as well as Section 3.1.1 in this
document). All messages MUST contain
* an SCEP transactionID attribute
* an SCEP messageType attribute
* an SCEP senderNonce attribute
* any attributes required by PKCS#7 [RFC2315] section 9.2
If the message is a response, it MUST also include
* an SCEP pkiStatus attribute
* an SCEP responderNonce attribute
Nourse & Vilhuber Expires October 3, 2009 [Page 19]
Internet-Draft SCEP April 2009
3.1.1. Signed Transaction Attributes
The following transaction attributes are encoded as authenticated
attributes, and are carried, as specified in PKCS#7 [RFC2315] Section
9.2, in the SignerInfo for this signedData.
Please refer to Appendix B for the OID definitions.
+----------------+-----------------+---------------------------+
| Attribute | Encoding | Comment |
+----------------+-----------------+---------------------------+
| transactionID | PrintableString | Hash value as a string |
| messageType | PrintableString | Decimal value as a string |
| pkiStatus | PrintableString | Decimal value as a string |
| failInfo | PrintableString | Decimal value as a string |
| senderNonce | OctetString | |
| recipientNonce | OctetString | |
+----------------+-----------------+---------------------------+
Transaction Attributes
The attributes are detailed in the following sections.
3.1.1.1. transactionID
The transactionID is an attribute that uniquely identifies a
transaction. This attribute MUST be included in all PKI messages.
The transactionID SHOULD be the MD5 hash of the public key from the
request, encoded as a PrintableString. The transactionID MUST be
unique to a given public key, so that any new requests for
certificates using the same key can be detected as duplicates by the
server (see Section 8.4).
For a non-enrollment message (for example GetCert and GetCRL), the
transactionID SHOULD be a number unique to the client.
3.1.1.2. messageType
The messageType attribute specifies the type of operation performed
by the transaction. This attribute MUST be included in all PKI
messages. Currently, the following message types are defined:
o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request
o CertRep (3) -- Response to certificate or CRL request
Nourse & Vilhuber Expires October 3, 2009 [Page 20]
Internet-Draft SCEP April 2009
o GetCertInitial (20) -- Certificate polling in manual enrollment
o GetCert (21) -- Retrieve a certificate
o GetCRL (22) -- Retrieve a CRL
3.1.1.3. pkiStatus
All response messages MUST include transaction status information,
which is defined as pkiStatus attribute:
o SUCCESS (0) -- request granted
o FAILURE (2) -- request rejected. When pkiStatus is FAILURE, the
failInfo attribute, as defined in Section 3.1.1.4, MUST also be
present.
o PENDING (3) -- request pending for manual approval
3.1.1.4. failInfo
The failInfo attribute MUST contain one of the following failure
reasons:
o badAlg (0) -- Unrecognized or unsupported algorithm identifier
o badMessageCheck (1) -- integrity check failed
o badRequest (2) -- transaction not permitted or supported
o badTime (3) -- The signingTime attribute from the PKCS#7
SignedAttributes was not sufficiently close to the system time
(see Section 3.1.1.6).
o badCertId (4) -- No certificate could be identified matching the
provided criteria
3.1.1.5. senderNonce and responderNonce
The attributes of senderNonce and recipientNonce are 16 byte random
numbers generated for each transaction to prevent replay attacks.
When a requester sends a PKI message to the server, a senderNonce
MUST be included in the message.
The responder SHOULD copy the senderNonce into the recipientNonce of
the reply as a proof of liveliness.
Nourse & Vilhuber Expires October 3, 2009 [Page 21]
Internet-Draft SCEP April 2009
The requester SHOULD verify that the recipientNonce of the reply
matches the senderNonce it sent in the request.
3.1.1.6. signingTime Attribute
The signingTime Attribute is defined in [RFC2985] Section 5.3.3, and
is carried as defined in a [RFC2315] authenticated attribute (Section
9.2). This attribute is optional.
3.1.2. SCEP pkcsPKIEnvelope
The information portion of a SCEP message is carried inside an
enveloped-data content type, as defined in PKCS#7 [RFC2315] Section
10, with the following restrictions:
o version MUST be 0
o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as
defined in PKCS#7 [RFC2315] Section 8.
o encryptedContent MUST be the SCEP message being transported (see
Section 4), and must match the messageType signedAttribute in the
pkiMessage.
The message is encrypted using the public key of the recipient of the
message, i.e. the RA or the CA public key (if sent from the
requester), or the requester public key (if sent as a reply to the
requester).
3.2. SCEP pkiMessage types
All of the messages in this section are pkiMessages (Section 3.1),
where the type of the message MUST be specified in the 'messageType'
Signed Attribute. Each section defines a valid message type, the
corresponding messageData formats, and mandatory signed attributes
for that type.
3.2.1. PKCSReq
The messageData for this type consists of a DER-encoded PKCS#10
Certification Request [RFC2986]. The certification request MAY
contain any fields defined in PKCS#10 [RFC2986], and MUST contain at
least the following items:
o the subject Distinguished Name
o the subject public key
Nourse & Vilhuber Expires October 3, 2009 [Page 22]
Internet-Draft SCEP April 2009
o a challengePassword attribute. The Challenge Password may be used
to (out-of-band) authenticate the enrollment request itself, or in
an out-of-band revocation request for the issued certificate.
In addition to the authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following
attributes:
o a transactionID (Section 3.1.1.1) attribute
o a messageType (Section 3.1.1.2) attribute set to PKCSReq
o a senderNonce (Section 3.1.1.5) attribute
The pkcsPKIEnvelope for this message type is encrypted using the
public key of the recipient, i.e. the CA or RA public key.
3.2.2. CertRep
The messageData for this type consists of a DER-encoded degenerate
certificates-only Signed-data (Section 3.3). The exact contents
required for certain CertRep replies depends on the type of request
this message is a reply to and is detailed in Table 1 and in
Section 4.
In addition to the authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following
attributes:
o the transactionID (Section 3.1.1.1) attribute copied from the
request we are responding to
o a messageType (Section 3.1.1.2) attribute set to CertRep
o a senderNonce (Section 3.1.1.5) attribute
o a recipientNonce attribute (Section 3.1.1.5) copied from the
senderNonce from the request we are responding to.
o a pkiStatus (Section 3.1.1.3) set to the status of the reply.
The pkcsPKIEnvelope of a CertRep (if present), MUST be encrypted with
the same certificate used to sign the PKCSReq this message is a reply
to, according to section 10 in PKCS#7 [RFC2315]. This means that if
a self-signed certificate was used to send the request, this self-
signed certificate will be reflected in the recipientInfo field of
the envelopedData, in accordance with PKCS#7 [RFC2315] section 10.
Nourse & Vilhuber Expires October 3, 2009 [Page 23]
Internet-Draft SCEP April 2009
3.2.2.1. CertRep SUCCESS
When the pkiStatus attribute is set to SUCCESS, the messageData for
this message consists of a DER-encoded degenerate certificates-only
Signed-data (Section 3.3). The contents of this degenerate
certificatess-only Signed-Data depends on what the original request
was, as outlined in Table 1.
+----------------+--------------------------------------------------+
| Request-type | Reply-contents |
+----------------+--------------------------------------------------+
| PKCSReq | the reply MUST contain at least the issued |
| | certificate attached to the certificates field |
| | of the Signed-Data. The reply MAY contain |
| | additional certificates, but the issued |
| | certificate MUST be the first in the list. The |
| | reply MUST NOT contain any CRL's. All returned |
| | certificates MUST conform to [RFC5280]. |
| GetCertInitial | same as PKCSReq |
| GetCert | the reply MUST contain at least the requested |
| | certificate attached to the certificates field |
| | of the Signed-Data. The reply MAY contain |
| | additional certificates, but the requested |
| | certificate MUST be the first in the list. The |
| | reply MUST NOT contain any CRL's. All returned |
| | certificates MUST conform to [RFC5280]. |
| GetCRL | the reply MUST contain the CRL attached to the |
| | crls field of the Signed-Data. The reply MUST |
| | NOT contain any certificates. The CRL MUST be a |
| | valid CRL according to [RFC5280]. |
+----------------+--------------------------------------------------+
Table 1: CertRep Types
3.2.2.2. CertRep FAILURE
When the pkiStatus attribute is set to FAILURE, the reply MUST also
contain a failInfo (Section 3.1.1.4) attribute set to the appropriate
error condition decribing the failure. The pkcsPKIEnvelope
(Section 3.1.2) MUST be omitted.
3.2.2.3. CertRep PENDING
When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope
(Section 3.1.2) MUST be omitted.
Nourse & Vilhuber Expires October 3, 2009 [Page 24]
Internet-Draft SCEP April 2009
3.2.3. GetCertInitial
The messageData for this type consists of a DER-encoded
IssuerAndSubject (Section 3.2.3.1). The issuer is set to the
issuerName from the certification authority from which we are issued
certificates. The Subject is set to the SubjectName we used when
requesting the certificate.
In addition to the authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following
attributes:
o the same transactionID (Section 3.1.1.1) attribute from original
PKCSReq message
o a messageType (Section 3.1.1.2) attribute set to GetCertInitial
o a senderNonce (Section 3.1.1.5) attribute
3.2.3.1. IssuerAndSubject
Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section
6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7).
The ASN.1 definition of the issuerAndSubject type is as follows:
issuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name
}
Figure 7: IssuerAndSubject ASN.1
3.2.4. GetCert
The messageData for this type consists of a DER-encoded
IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 containing
the "distinguished name of the certificate issuer and an issuer-
specific certificate serial number" which uniquely identifies the
certificate we are requesting.
In addition to the authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following
attributes:
o a transactionID (Section 3.1.1.1) attribute
o a messageType (Section 3.1.1.2) attribute set to PKCSReq
Nourse & Vilhuber Expires October 3, 2009 [Page 25]
Internet-Draft SCEP April 2009
o a senderNonce (Section 3.1.1.5) attribute
If this is a query for its own certificate (assume the requester lost
the issued certificate, or does not have enough non-volatile memory
to save the certificate), then a self-signed certificate has to be
included in the signed envelope.
3.2.5. GetCRL
The messageData for this type consists of a DER-encoded
IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7. The
issuer is set to the SubjectName of the certification authority which
issued the certificate revocation list we are requesting. The serial
number is the CA certificate's serial number.
In addition to the authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following
attributes:
o a transactionID (Section 3.1.1.1) attribute
o a messageType (Section 3.1.1.2) attribute set to PKCSReq
o a senderNonce (Section 3.1.1.5) attribute
3.3. Degenerate certificates-only PKCS#7 Signed-data
[RFC2315] section 9 mentions a degenerate case of the PKCS#7 Signed-
data content type, in which there are no signers. The use of such a
degenerate case is to disseminate certificates and certificate-
revocation lists. SCEP makes use of this degenerate case, calling it
a "degenerate certificates-only PKCS#7 Signed-data". Though not
required by PKCS#7 [RFC2315], for SCEP the ContentInfo of a
degenerate certificates-only Signed-Data MUST be empty.
When carrying certificates, the certificates are attached to the
'certificates' field of the Signed-Data. When carrying a CRL, the
CRL will be attached to the 'crls' field of the Signed-Data.
4. SCEP Transactions
This section describes the SCEP Transactions, without explaining the
transport. The transport of each message is discussed in Section 5.
Some of the transaction-requests have no data to send, i.e. the only
data is the message-type itself (e.g. a GetCaCert message has no
additional data). The use of such messages will become clearer in
Section 5.
Nourse & Vilhuber Expires October 3, 2009 [Page 26]
Internet-Draft SCEP April 2009
In this section, each SCEP transaction is specified in terms of the
complete messages exchanged during the transaction.
The order of the transactions in this section is mirrored in
Section 5.2 for better organization and readability.
4.1. Get CA Certificate
To get the CA certificate(s), the requester sends a GetCACert message
to the server. There is no request data associated with this message
(see Section 5.2.1).
4.1.1. Get CA Certificate Response Message Format
The response depends on whether the responding server has RA
certificates or only a single CA certificate. The server MUST
indicate which response it is sending via the transport protocol used
(see Section 5.2.1).
All returned certificates MUST conform to [RFC5280].
Once the CA certificate is received by the requester (regardless of
the presence of RA certificates), a fingerprint is generated using
the SHA1, SHA256, SHA512 or MD5 hash algorithm on the whole CA
certificate. If the requester does not have a certificate path to a
trusted CA certificate, this fingerprint may be used to verify the
certificate, by some positive out-of-band means, such as a phone call
or pre-provisioning.
4.1.1.1. CA Certificate Response Message Format
If the server is a certification authority and does not have any RA
Certificates, the response consists of a single DER-encoded X.509 CA
certificate.
4.1.1.2. CA/RA Certificate Response Message Format
If the server has RA Certificates, the response consists of a DER-
encoded degenerate certificates-only Signed-data (Section 3.3)
containing the CA certificate and RA certificates.
4.2. Certificate Enrollment
A PKCSReq (Section 3.2.1) message is used to perform a certificate
enrollment transaction.
The reply MUST be a CertRep (Section 3.2.2) message sent back from
the server, indicating SUCCESS, FAILURE, or PENDING.
Nourse & Vilhuber Expires October 3, 2009 [Page 27]
Internet-Draft SCEP April 2009
Precondition: Both the requester and the certification authority have
completed their initialization process. The requester has already
been configured with the CA/RA certificate.
Postcondition: Either the certificate is received by the requester,
or the end entity is notified to do the manual authentication, or the
request is rejected.
4.2.1. Certificate Enrollment Response Message
If the request is granted, a CertRep (Section 3.2.2) message with
pkiStatus set to SUCCESS is returned. The reply MUST also contain
the certificate (and MAY contain any other certificates needed by the
requester). The issued certificate MUST be the first in the list.
If the request is rejected, a CertRep (Section 3.2.2) message with
pkiStatus set to FAILURE is returned. The reply MUST also contain a
failInfo attribute.
If the the CA is configured to manually authenticate the requester, a
CertRep (Section 3.2.2) message with pkiStatus set to PENDING is
returned..
4.3. Poll for Requester Initial Certificate
Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING,
a requester will enter the polling state by periodically sending
GetCertInitial (Section 3.2.3) to the server, until either the
request is granted and the certificate is sent back, or the request
is rejected, or the configured time limit for polling (or maximum
number of polls) is exceeded.
Since GetCertInitial is part of the enrollment, the messages
exchanged during the polling period should carry the same
transactionID attribute as the previous PKCSReq. A server receiving
a GetCertInitial for which it does not have a matching PKCSReq MUST
ignore this request.
Since at this time the certificate has not been issued, the requester
can only use its own subject name (which was contained in the
original PKCS#10 sent via PKCSReq) to identify the polled certificate
request. Since there can be multiple outstanding requests from one
requester (for example, if different keys and different key-usages
were used to request multiple certificates), the transaction ID must
also be included, to disambiguate between multiple requests.
PreCondition: Either the requester has received a CertRep with
pkiStatus set to PENDING, or waiting for a previous PKCSReq has timed
Nourse & Vilhuber Expires October 3, 2009 [Page 28]
Internet-Draft SCEP April 2009
out.
PostCondition: The requester has either received a valid response,
which could be either a valid certificate (pkiStatus == SUCCESS), or
a FAILURE message, or the polling period times out.
4.3.1. Polling Response Message Format
The response messages for GetCertInitial are the same as in
Section 4.2.1.
4.4. Certificate Access
The certificate query message is an option when the LDAP server is
not available to provide the certificate query. A requester should
be able to query an issued certificate from the certification
authority, as long as the issuer name and the issuer assigned
certificate serial number is known to the requesting end entity.
This transaction is not intended to provide the service as a
certificate directory service. A more complicated query mechanism
would have to be defined in order to allow a requester to query a
certificate using various different fields.
This transaction consists of one GetCert (Section 3.2.4) message sent
to the server by a requester, and one CertRep (Section 3.2.2) message
sent back from the server.
PreCondition: The queried certificate have been issued by the
certification authority and the issuer assigned serial number is
known.
PostCondition: Either the certificate is sent back or the request is
rejected.
4.4.1. Certificate Access Response Message Format
In this case, the CertRep from the server is same as in
Section 4.2.1, except that the server will only either grant the
request (SUCCESS) or reject the request (FAILURE).
Also, the recipientInfo should use the CA issuer name and CA assigned
serial number to identify the requester's key pair since at this
time, the requester has received its own certificate.
4.5. CRL Access
The CRL query message is an option when the LDAP server is not
available to provide the CRL query. In the PKI protocol proposed
Nourse & Vilhuber Expires October 3, 2009 [Page 29]
Internet-Draft SCEP April 2009
here, only the requester can initiate the transaction to download
CRL.
A requester sends GetCRL (Section 3.2.5) request to the server and
the server sends back CertRep (Section 3.2.2) whose information
portion is a degenerate certificates-only Signed-data (Section 3.3)
which contains only the most recent CRL. The size of CRL included in
the CertRep should be determined by the implementation.
When a CRLDistributionPoint is used, the GetCRL exchange should not
be used. Instead, the CRLDistributionPoint, as set in the
certificate, should be queried (see [RFC5280] section 4.2.1.14).
PreCondition: The certification authority certificate has been
downloaded to the end entity.
PostCondition: CRL sent back to the requester.
4.5.1. CRL Access Response Message Format
The CRL is sent back to the requester through CertRep message. The
information portion of this message is a degenerate certificates-only
Signed-data (Section 3.3) which contains only CRL attached to the
crls field of the Signed-Data.
4.6. Get Next Certification Authority Certificate
When a CA certificate is about to expire, clients need to retrieve
the CA's next CA certificate (i.e. the Rollover Certificate). This
is done via the GetNextCaCert message. There is no request data
associated with this message (see Section 5.2.6).
4.6.1. Get Next CA Response Message Format
The response consists of a SignedData PKCS#7 [RFC2315], signed by the
current CA (or RA) signing key.
Clients MUST validate the signature on the the SignedData PKCS#7
[RFC2315] before accepting any of its contents.
The content of the SignedData PKCS#7 [RFC2315] is a degenerate
certificates-only Signed-data (Section 3.3) message containing the
new CA certificate and any new RA certificates, as defined in
Section 5.2.1.1.2, to be used when the current CA certificate
expires.
If the CA (or RA) does not have the Rollover certificate(s) it MUST
reject the request. It SHOULD also remove the GetNextCaCert setting
Nourse & Vilhuber Expires October 3, 2009 [Page 30]
Internet-Draft SCEP April 2009
from the capabilities until it does have rollover certificates.
If there are any RA certificates in this response, clients MUST check
that these RA certificates are signed by the CA, and MUST check
authorization of these RA certificates (see Section 2.1.3).
5. Transport Protocol
In the SCEP protocol, HTTP is used as the transport protocol for the
PKI messages.
5.1. HTTP "GET" Message Format
SCEP uses the HTTP "GET" messages to request information from the CA.
The following is the syntax definition of a HTTP GET message sent
from a requester to a certification authority server:
"GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE
General GET Syntax
where:
o CGI-PATH defines the actual CGI path to invoke the CGI program
that parses the request.
o CGI-PROG is set to be the string "pkiclient.exe". This is
intended to be the program that the CA will use to handle the SCEP
transactions, though the CA may ignore CGI-PROG and use only the
CGI-PATH.
o OPERATION depends on the SCEP transaction and is defined in the
following sections.
o MESSAGE depends on the SCEP transaction and is defined in the
following sections.
If the CA supports it, requests may also be done via an HTTP POST.
This is described in Appendix F.
5.1.1. Response Message Format
For each GET operation, the CA/RA server MUST return a Content-Type
and appropriate response data, if any.
Nourse & Vilhuber Expires October 3, 2009 [Page 31]
Internet-Draft SCEP April 2009
5.2. SCEP HTTP Messages
5.2.1. GetCACert
OPERATION MUST be set to "GetCACert".
MESSAGE MAY be ommitted, or it MAY be a string that represents the
certification authority issuer identifier, if such has been set by
the CA Administrator.
5.2.1.1. GetCACert Response
The response for GetCACert is different between the case where the CA
directly communicated with the requester during the enrollment, and
the case where a RA exists and the requester communicates with the RA
during the enrollment.
5.2.1.1.1. CA Certificate Only Response
The response will have a Content-Type of "application/
x-x509-ca-cert".
The body of this response consists of a DER-encoded X.509 CA
certificate, as defined in Section 4.1.1.1.
"Content-Type:application/x-x509-ca-cert\n\n"<BER-encoded X.509>
CA Certificate Response
5.2.1.1.2. CA and RA Certificates Response
The response will have a Content-Type of "application/
x-x509-ca-ra-cert".
The body of this response consists of a DER-encoded degenerate
certificates-only Signed-data (Section 3.3) containing both CA and RA
certificates, as defined in Section 4.1.1.2.
"Content-Type:application/x-x509-ca-ra-cert\n\n"<BER-encoded PKCS7>
RA Certificate Response
5.2.2. PKCSReq
OPERATION MUST be set to "PKIOperation".
MESSAGE consists of a base64-encoded DER-encoded PKCSReq SCEP
message.
An example PKIOperation request might look as follows:
Nourse & Vilhuber Expires October 3, 2009 [Page 32]
Internet-Draft SCEP April 2009
GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0
PKCSReq Example
5.2.2.1. PKCSReq Response
The response will have a Content-Type of "application/x-pki-message".
The body of this response consists of a DER-encoded CertRep SCEP
message defined in Section 4.2.1. The following is an example of the
response:
"Content-Type:application/x-pki-message\n\n"<BER-encoded CertRep msg>
CertRep Example
5.2.3. GetCertInitial
OPERATION MUST be set to "PKIOperation".
MESSAGE consists of a base64-encoded DER-encoded GetCertInitial SCEP
message.
5.2.3.1. GetCertInitial Response
The body of this response consists of a DER-encoded CertRep SCEP
message defined in Section 4.3.1.
5.2.4. GetCert
OPERATION MUST be set to "PKIOperation".
MESSAGE consists of a base64-encoded DER-encoded GetCert SCEP
message.
5.2.4.1. GetCert Response
The body of this response consists of a DER-encoded CertRep SCEP
message defined in Section 4.4.1.
5.2.5. GetCRL
OPERATION MUST be set to "PKIOperation".
MESSAGE consists of a base64-encoded DER-encoded GetCRL SCEP message.
Nourse & Vilhuber Expires October 3, 2009 [Page 33]
Internet-Draft SCEP April 2009
5.2.5.1. GetCRL Response
The body of this response consists of a DER-encoded CertRep SCEP
message defined in Section 4.5.1.
5.2.6. GetNextCaCert
OPERATION MUST be set to "GetNextCaCert".
MESSAGE MAY be ommitted, or it MAY be a string that represents the
certification authority issuer identifier, if such has been set by
the CA Administrator.
5.2.6.1. GetNextCACert Response
The response will have a Content-Type of "application/
x-x509-next-ca-cert".
The body of this response consists of a SignedData PKCS#7 [RFC2315],
as defined in Section 4.6.1.
"Content-Type:application/x-x509-ca-ra-cert\n\n"
<BER-encoded SignedData<BER-encoded degenerate PKCS7>>
GetNextCaCert Example
6. Contributors/Acknowledgements
The editor would like to thank all the previous authors: Cheryl
Madson, Xiaoyi Liu, David McGrew, etc for their work on the draft
over the years.
The authors would like to thank Peter William of ValiCert, Inc.
(formerly of VeriSign, Inc) and Alex Deacon of VeriSign, Inc. and
Christopher Welles of IRE, Inc. for their contributions to this
protocol and to this document.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
Nourse & Vilhuber Expires October 3, 2009 [Page 34]
Internet-Draft SCEP April 2009
8.1. General Security
Common key-management considerations such as keeping private keys
truly private and using adequate lengths for symmetric and asymmetric
keys must be followed in order to maintain the security of this
protocol.
This is especially true for CA keys, which, when compromised,
compromise the security of all relying parties.
8.2. Use of the CA keypair
A CA key pair is generally meant for (and is usually flagged as)
"certificate signing" (exclusively), rather than 'data signing' or
'data encryption'. The SCEP protocol, however, uses the CA key pair
to encrypt and sign PKCS#7 [RFC2315] transport messages, regardless
of the key usage of the CA certificate. This is generally considered
undesirable, as it widens the possibility of an implementation
weakness, and provides
o another place that the private key must be used (and hence is
slightly more vulnerable to exposure),
o another place where a side channel attack (say, timing or power
analysis) might be used,
o another place that the attacker might somehow insert his own text,
and get it signed by the private key.
While the CA key pair can be generated with the 'data encryption' and
'data signing' flags set, this is operationally not encouraged. It
would make using the key as a PKCS#7 [RFC2315] transport key 'legal',
but the discussion from the previous paragraph still applies.
A solution is to use RA keys to secure the SCEP transport (i.e.
message signing and encrypting), which allows the CA keys to be used
only for their intended purpose of "certificate signing".
An RA can be implemented in two ways: physically separate or
implicit. In the implicit case, the CA simply creates an extra key
pair. A physically separate RA allows the CA to be inside the secure
network, not accessible to hackers at all.
8.3. ChallengePassword
The challengePassword sent in the PKCS#10 enrollment request is
signed and encrypted by way of being encapsulated in a pkiMessage.
When saved by the CA, care should be taken to protect this password.
Nourse & Vilhuber Expires October 3, 2009 [Page 35]
Internet-Draft SCEP April 2009
If the challengePassword is used to automatically authenticate an
enrollment request, it is recommended that some form of one-time
password be used to minimize damage in the event the data is
compromised.
8.4. transactionID
A well-written CA/RA SHOULD NOT rely on the transactionID to be
correct or as specified in this document. Requesters with buggy
software might add additional undetected duplicate requests to the
CA's queue (or worse). A well-written CA/RA should never assume the
data from a requester is well-formed.
On the other hand, a CA/RA MAY use the transactionID to reject
previously handled requests with the same transactionID, reducing
operational overhead. This has the side-effect, that ill-behaved
clients will not receive a successful response to requests using the
same transactionID.
8.5. Nonces and Replay
In order to detect replay attacks, both sides need to maintain state
information sufficient to detect a repeated, duplicate senderNonce.
Since existing implementations do not copy the senderNonce from a
CertRep into subsequent GetCertinitial requests, the server will
never see its own nonce reflected back to it. The transactionID
links together the GetCertInitial and PKCSReq, in any case.
8.6. Key Usage Issues
When building a pkiMessage, clients MUST have a certificate to sign
the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires
it). Client can either use an existing certificate, or they MUST
create a self-signed certificate (see Section 2.1.2.6.3). If this
certificate has a key usage extension with it, then this key usage
MUST be ignored by both the SCEP client and SCEP server for the
duration of the transaction (the key will be used for signing during
the creation of the PKCSReq message, and for encryption during the
creation of the CertRep message).
8.7. GetCACaps Issues
The GetCACaps response is not signed. This allows an attacker to use
downgrade attacks (as well as "upgrade attacks") on the cryptographic
capabilities of the CA.
Nourse & Vilhuber Expires October 3, 2009 [Page 36]
Internet-Draft SCEP April 2009
8.8. Unnecessary cryptography
Some of the SCEP exchanges use signing and encryption operations that
are not necessary. In particular the GetCert and GetCRL exchanges
are encrypted and signed (in both directions), where simply signing
the request would suffice (CRL's and Certificates, i.e. the
respective responses, are already signed by the CA and can be
verified by the recipient).
This may affect performance and scalability of the CA which could be
used as an attack vector on the CA (though not an anonymous one).
The use of CDP's is recommended for CRL access, as well as other ways
of retrieving certificates (LDAP, direct HTTP access, etc).
8.9. GetNextCaCert
Versions of SCEP prior to 19 do not specifiy a correct GetNextCaCert
response.
Versions of SCEP prior to revision 3 do not support GetNextCACert.
9. Intellectual Property
This protocol includes the optional use of Certificate Revocation
List Distribution Point (CRLDP) technology, which is a patented
technology of Entrust Technologies, Inc. (Method for Efficient
Management of Certificate Revocation Lists and Update Information
(U.S. Patent 5,699,431)). Please contact Entrust Technologies, Inc.
(www.entrust.com) for more information on licensing CRLDP technology.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
November 2000.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Nourse & Vilhuber Expires October 3, 2009 [Page 37]
Internet-Draft SCEP April 2009
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Appendix A. IPSEC Client Enrollment Certificate Request
The following is the certificate enrollment request (PKCS#10
[RFC2986]) as created by Cisco VPN Client:
-----END NEW CERTIFICATE REQUEST-----
0 30 439: SEQUENCE {
4 30 288: SEQUENCE {
8 02 1: INTEGER 0
11 30 57: SEQUENCE {
13 31 55: SET {
15 30 53: SEQUENCE {
17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
22 13 46: PrintableString
: 'For Xiaoyi, IPSEC attrs in alternate name
extn'
: }
: }
: }
70 30 158: SEQUENCE {
73 30 13: SEQUENCE {
75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1
1 1)
86 05 0: NULL
Nourse & Vilhuber Expires October 3, 2009 [Page 38]
Internet-Draft SCEP April 2009
: }
88 03 140: BIT STRING 0 unused bits
: 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E
: AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2
: CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6
: 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4
: 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F
: 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA
: 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19
: E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18
: [ Another 11 bytes skipped ]
: }
231 A0 63: [0] {
233 30 61: SEQUENCE {
235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9
14)
246 31 48: SET {
248 30 46: SEQUENCE {
250 30 44: SEQUENCE {
252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
257 04 37: OCTET STRING
30 23 87 04 01 02 03 04 81 0D 65 6D 61 69
6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64
6E 2E 69 72 65 2E 63 6F 6D
: }
: }
: }
: }
: }
: }
296 30 13: SEQUENCE {
298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549
1 1 4)
309 05 0: NULL
: }
311 03 129: BIT STRING 0 unused bits
: 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A
: 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60
: 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7
: 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D
: C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91
: B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0
: A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24
: 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7
: }
Nourse & Vilhuber Expires October 3, 2009 [Page 39]
Internet-Draft SCEP April 2009
Certificate Enrollment Request
Appendix B. Private OID Definitions
The OIDs used in SCEP are VeriSign self-maintained OIDs.
+-------------------+-----------------------------------------------+
| Name | ASN.1 Definition |
+-------------------+-----------------------------------------------+
| id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 |
| | VeriSign(113733)} |
| id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} |
| id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} |
| id-messageType | OBJECT_IDENTIFIER ::= {id-attributes |
| | messageType(2)} |
| id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes |
| | pkiStatus(3)} |
| id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes |
| | failInfo(4)} |
| id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes |
| | senderNonce(5)} |
| id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes |
| | recipientNonce(6)} |
| id-transId | OBJECT_IDENTIFIER ::= {id-attributes |
| | transId(7)} |
| id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes |
| | extensionReq(8)} |
+-------------------+-----------------------------------------------+
Appendix C. SCEP State Transitions
SCEP state transitions are indexed by the transactionID attribute.
The design goal is to ensure the synchronization between the CA and
the requester under various error situations.
Each enrollment transaction is uniquely associated with a transaction
identifier (carried in the transactionID signed attribute (see
Section 3.1.1.1). Because the enrollment transaction could be
interrupted by various errors, including network connection errors or
client reboot, the SCEP client generates a transaction identifier by
calculating a hash on the public key value for which the enrollment
is requested. This retains the same transaction identifier
throughout the enrollment transaction, even if the client has
rebooted or timed out, and issues a new enrollment request for the
same key pair. It also provides the way for the CA to uniquely
identify a transaction in its database. At the requester side, it
Nourse & Vilhuber Expires October 3, 2009 [Page 40]
Internet-Draft SCEP April 2009
generates a transaction identifier which is included in PKCSReq. If
the CA returns a response of PENDING, the requester will poll by
periodically sending out GetCertInitial with the same transaction
identifier until either a response other than PENDING is obtained, or
the configured maximum time has elapsed.
If the client times out or the client reboots, the client
administrator will start another enrollment transaction with the same
key pair. The second enrollment will have the transaction
identifier. At the server side, instead of accepting the PKCSReq as
a new enrollment request, it should respond as if another
GetCertInitial message had been sent with that transaction ID. In
another word, the second PKCSReq should be taken as a
resynchronization message to allow the enrollment resume as the same
transaction.
It is important to keep the transaction id unique since SCEP requires
the same policy and same identity be applied to the same subject name
and key pair binding. In the current implementation, an SCEP client
can only assume one identity. At any time, only one key pair, with a
given key usage, can be associated with the same identity.
The following gives several examples of client to CA transactions.
Client actions are indicated in the left column, CA actions are
indicated in the right column. A blank action signifies that no
message was received. Note that these examples assume that the CA
enforces the certificate-name uniqueness property defined in
Section 2.1.2.4.
The first transaction, for example, would read like this:
"Client Sends PKCSReq message with transaction ID 1 to the CA. The
CA signs the certificate and constructs a CertRep Message containing
the signed certificate with a transaction ID 1. The client receives
the message and installs the certificate locally."
Successful Enrollment Case: no manual authentication
PKCSReq (1) ----------> CA Signs Cert
Client Installs Cert <---------- CertRep (1) SIGNED CERT
Simple Enrollment Example
Nourse & Vilhuber Expires October 3, 2009 [Page 41]
Internet-Draft SCEP April 2009
Successful Enrollment Case: manual authentication required
PKCSReq (10) ----------> Cert Request goes into Queue
Client Polls <---------- CertRep (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (10) PENDING
GetCertInitial (10) ----------> Cert has been signed
<---------- CertRep (10) SIGNED CERT
Client Installs Cert
Enrollment with Pending
Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants
the certificate and returns SUCCESS, with the certificate. The
SUCCESS gets lost:
PKCSReq (3) ----------> Cert Request goes into queue
<---------- CertRep (3) PENDING
GetCertInitial (3) ---------->
<---------- CertRep (3) PENDING
GetCertInitial (3) ----------->
X-------- CA grants Cert
CertRep(3) SUCCESS
(Time Out)
PKCSReq (3) ----------> Cert already granted
<---------- CertRep (3) SUCCESS
Client Installs Cert
Resync Case 1
Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply
gets lost:
PKCSReq (3) ----------> Cert Request goes into queue
X-------- CertRep (3) PENDING
(Time Out)
PKCSReq (3) ---------->
<---------- CertRep (3) PENDING
etc...
Resync Case 2
Nourse & Vilhuber Expires October 3, 2009 [Page 42]
Internet-Draft SCEP April 2009
Case when the Certificate is lost and client has to generate a new
key pair, there is no change of name information:
PKCSReq (4) ----------> CA Signs Cert
<---------- CertRep (4) SIGNED CERT
Client Installs Cert
(Client looses Cert)
PKCSReq (5) ----------> There is already a valid cert with
this DN.
<---------- CertRep (5) BAD REQUEST
Admin Revokes
PKCSReq (5) ----------> CA Signs Cert
<---------- CertRep (5) SIGNED CERT
Client Installs Cert
Retrieving lost certificate
Appendix D. CA Capabilities
D.1. GetCACaps HTTP Message Format
"GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT
This message requests capabilities from CA. The response is a list
of text capabilities, as defined in Appendix D.2. Support for this
message is optional, but if it is not supported, the client should
assume that none of the capabilities in Appendix D.2 are supported.
D.2. CA Capabilities Response Format
The response for a GetCACaps message is a list of CA capabilities, in
plain text, separated by <LF> characters, as follows (quotation marks
are NOT sent):
+--------------------+----------------------------------------------+
| Keyword | Description |
+--------------------+----------------------------------------------+
| "GetNextCACert" | CA Supports the GetNextCACert message. |
| "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP |
| | POST. |
| "Renewal" | Clients may use current certificate and key |
| | to authenticate an enrollment request for a |
| | new certificate. |
| "SHA-512" | CA Supports the SHA-512 hashing algorithm in |
| | signatures and fingerprints. |
| "SHA-256" | CA Supports the SHA-256 hashing algorithm in |
| | signatures and fingerprints. |
Nourse & Vilhuber Expires October 3, 2009 [Page 43]
Internet-Draft SCEP April 2009
| "SHA-1" | CA Supports the SHA-1 hashing algorithm in |
| | signatures and fingerprints. |
| "DES3" | CA Supports triple-DES for encryption. |
+--------------------+----------------------------------------------+
The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5
hashing if it is supported by the CA.
A client MUST be able to accept and ignore any unknown keywords that
might be sent back by a CA.
If none of the above capabilities are supported by the CA, a server
SHOULD return an empty message. A server MAY simple return an HTTP
error.
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD
ignore the Content-type, as servers implementing early version of the
SCEP draft may send various Content-types.
Example:
GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca
GetCaCaps request
might return:
GetNextCACert<LF>POSTPKIOperation
GetCaCaps reply example
This means that the CA supports the GetNextCACert message and allows
PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be
sent using HTTP POST.
Appendix E. Certificate Renewal and CA Key Rollover
To renew a client certificate, use the PKCSreq message and sign it
with the existing client certificate instead of a self-signed
certificate.
To obtain the new CA certificate prior to the expiration of the
current one, use the GetNextCACert message if the CA supports it.
To obtain a new client certificate signed by the new CA certificate,
use the new CA or RA certificate in the message envelope. Example:
Nourse & Vilhuber Expires October 3, 2009 [Page 44]
Internet-Draft SCEP April 2009
GetNextCACert ---------->
<---------- New CA certificate
PKCSReq* ----------> CA Signs certificate with NEW key
Client Stores Cert <---------- CertRep - Certificate issued
for installation when from NEW CA certificate and key pair
existing cert expires.
*enveloped for new CA or RA cert and key pair. The CA will use the
envelope to determine which key and certificate to use to issue the
client certificate.
GetNextCaCert Transaction
Appendix F. PKIOperation via HTTP POST Message
If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded
SCEP messages may be sent via HTTP POST instead of HTTP GET. This is
allowed for any SCEP message except GetCACert, GetNextCACert, or
GetCACaps. In this form of the message, Base 64 encoding is not
used.
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0
Content-Length: <length of data>
<binary PKCS#7 data>
General POST Syntax
The client can verify that the CA supports SCEP messages via POST by
looking for the "POSTPKIOperation" capability (See Appendix D).
Authors' Addresses
Andrew Nourse
Cisco Systems, Inc
510 McCarthy Drive
Milpitas, CA
USA
Phone:
Fax:
Email:
URI:
Nourse & Vilhuber Expires October 3, 2009 [Page 45]
Internet-Draft SCEP April 2009
Jan Vilhuber (editor)
Cisco Systems, Inc.
510 McCarthy Drive
Milpitas, CA
USA
Email: vilhuber@cisco.com
Nourse & Vilhuber Expires October 3, 2009 [Page 46]
