WDIFF

draft-nourse-scep-18.txt --> draft-nourse-scep-19.txt

Internet Engineering Task Force A. Nourse
Internet-Draft X. Liu Cisco Systems, Inc
Intended status: Informational Historic J. Vilhuber Vilhuber, Ed.
Expires: July 25, October 3, 2009 C. Madson Cisco Systems, Inc.
January 21,
April 2009

Cisco Systems' Simple Certificate Enrollment Protocol
draft-nourse-scep-18
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 July 25, October 3, 2009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Nourse, et al. Expires July 25, 2009 [Page 1]

Internet-Draft SCEP January 2009

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. PKCS#10 over HTTP. SCEP is the evolution of the
enrollment protocol developed by Verisign, 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. The Goal of SCEP . . . Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
2.1. SCEP Entity Types Entities . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Requesters Requester . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.1. Local Key/Certificate/CRL Storage and
Certificate-name uniqueness Requester Initialization . . . . . . . . . . . 7
2.1.1.2. Requester authentication . . 6
2.1.1.2. Trusted CA Store . . . . . . . . . . . 8
2.1.1.3. Requester Uses Existing CA-Issued or
Self-Signed Certificates . . . . . . 7
2.1.2. Certification Authority . . . . . . . 9
2.1.1.4. Trusted CA Store . . . . . . . . 7
2.1.2.1. CA Certificate Fingerprint . . . . . . . . . 10
2.1.2. Certificate Authority . . . 8
2.1.2.2. Certification Authority Policies . . . . . . . . . 8
2.1.2.3. CRL's and CDP's . . . . 10
2.1.3. Registration Authorities . . . . . . . . . . . . . 8
2.1.2.4. Name Uniqueness . . 11
2.2. SCEP Operations Overview . . . . . . . . . . . . . . . 8
2.1.2.5. Retransmission versus new request . . 11
2.2.1. Requester Initialization . . . . . . 8
2.1.2.6. Requester authentication . . . . . . . . . 11
2.2.1.1. RSA Key Pairs . . . . 9
2.1.3. Registration Authority . . . . . . . . . . . . . . 11
2.2.1.2. non-RSA Keys . . 11
2.2. SCEP Functionality . . . . . . . . . . . . . . . . . 11
2.2.1.3. Required Information . . . 11
2.2.1. CA/RA Certificate Distribution . . . . . . . . . . . . 11
2.2.2. CA/RA Certificate Distribution Enrollment . . . . . . . . . . . . 12
2.2.3. Certificate Enrollment . . . . 12
2.2.2.1. State Transitions in Certificate Enrollment . . . 12
2.2.3. Certificate Access . . . . . . . . . 12
2.2.4. Requester Certificate Revocation . . . . . . . . . 14
2.2.4. CRL Access . . 13
2.2.5. Certificate Access . . . . . . . . . . . . . . . . . 14
2.2.6. CRL Distribution . . . 15
2.2.5. Certificate Revocation . . . . . . . . . . . . . . . . 14 16
2.3. PKI Operation Transactional Behavior . . . . . . . . . . . 15 16
2.3.1. Transaction Identifier . . . . . . . . . . . . . . . . 15 16
2.3.2. State Transitions in Certificate Enrollment . . . . . 15
2.3.3. Transaction Behavior of Certificate/CRL Access . . . . 16
2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 17
3. Transport Protocol SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 18
3.1. SCEP pkiMessage . . . . . 17
3.1. HTTP "GET" and "POST" Message Format . . . . . . . . . . . 18
3.2. Response Message Format . . . . . 19
3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 19
4. Secure Transportation: PKCS#7 20
3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 20
4.1. SCEP Message Format
3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 20
4.1.1. SCEP pkcsPKIEnvelope
3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . 20
4.1.2. SCEP pkiMessage type . . . 21
3.1.1.4. failInfo . . . . . . . . . . . . . . 21
4.2. Signed Transaction Attributes . . . . . . . 21
3.1.1.5. senderNonce and responderNonce . . . . . . . 21
4.2.1. transactionID . . . 21
3.1.1.6. signingTime Attribute . . . . . . . . . . . . . . 22
3.1.2. SCEP pkcsPKIEnvelope . . . 22

Nourse, et al. Expires July 25, 2009 [Page 2]

Internet-Draft SCEP January 2009

4.2.2. messageType . . . . . . . . . . . . . . 22
3.2. SCEP pkiMessage types . . . . . . . 22
4.2.3. pkiStatus . . . . . . . . . . . 22
3.2.1. PKCSReq . . . . . . . . . . . 22
4.2.4. failInfo . . . . . . . . . . . . 22
3.2.2. CertRep . . . . . . . . . . . 23
4.2.5. senderNonce and responderNonce . . . . . . . . . . . . 23
5. SCEP Transaction Specification
3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . 23
5.1. Certificate Enrollment . 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 . 23
5.1.1. PKCSReq Message Format . . . . . . . . . . . . . . . . 24
5.1.2. CertRep Message Format
3.2.3. GetCertInitial . . . . . . . . . . . . . . . . 24
5.1.2.1. PENDING Response . . . . 25
3.2.3.1. IssuerAndSubject . . . . . . . . . . . . . 25
5.1.2.2. FAILURE Response . . . . 25
3.2.4. GetCert . . . . . . . . . . . . . 25
5.1.2.3. SUCCESS response . . . . . . . . . . 25
3.2.5. GetCRL . . . . . . . 25
5.2. Poll for Requester Initial Certificate . . . . . . . . . . 25
5.2.1. GetCertInitial Message Format . . . . . . . 26
3.3. Degenerate certificates-only PKCS#7 Signed-data . . . . . 26
5.2.2. GetCertInitial Response Message Format . .
4. SCEP Transactions . . . . . . 26
5.3. Certificate Access . . . . . . . . . . . . . . . . 26
4.1. Get CA Certificate . . . . 26
5.3.1. GetCert Message Format . . . . . . . . . . . . . . . . 27
5.3.2. CertRep
4.1.1. Get CA Certificate Response Message Format . . . . . . . . . . 27
4.1.1.1. CA Certificate Response Message Format . . . . . . 27
5.4. CRL Access . .
4.1.1.2. CA/RA Certificate Response Message Format . . . . 27
4.2. Certificate Enrollment . . . . . . . . . . . . . . . . . . 28
5.4.1. GetCRL 27
4.2.1. Certificate Enrollment Response Message format . . . . . . . 28
4.3. Poll for Requester Initial Certificate . . . . . . . . . . 28
5.4.2. CertRep
4.3.1. Polling Response Message Format . . . . . . . . . . . . . . . . 28
5.5. Get Certificate Authority 29
4.4. Certificate Access . . . . . . . . . . 29
5.5.1. GetCACert HTTP Message Format . . . . . . . . . . . . 29
5.5.2.
4.4.1. Certificate Access Response Message Format . . . . . . 29
4.5. CRL Access . . . . . . . . . . . . . . . . . 29
5.5.2.1. CA Certificate Only Response . . . . . . . . . . . 29
5.5.2.2. CA and RA Certificates
4.5.1. CRL Access Response Message Format . . . . . . . . . . 30
5.5.3.
4.6. Get Next Certificate Certification Authority Certificate . . . . . . . 30
5.5.3.1. GetNextCACert HTTP
4.6.1. Get Next CA Response Message Format . . . . . . . . . 30
5.5.3.2. GetCACaps HTTP Message Format
5. Transport Protocol . . . . . . . . . . 30
5.6. Get Certificate Authority Certificate Chain . . . . . . . 30
5.6.1. GetCACertChain HTTP Message Format . . . . . 31
5.1. HTTP "GET" Message Format . . . . . 30
5.6.2. Response . . . . . . . . . . . 31
5.1.1. Response Message Format . . . . . . . . . . . . 30
5.6.3. Backwards Compatibility . . . 31
5.2. SCEP HTTP Messages . . . . . . . . . . . . 31
6. Acknowledgements . . . . . . . . 32
5.2.1. GetCACert . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . 32
5.2.1.1. GetCACert Response . . . . . . . . . . . . . . 31
8. Security Considerations . . 32
5.2.2. PKCSReq . . . . . . . . . . . . . . . . . 31
8.1. General Security . . . . . . 32
5.2.2.1. PKCSReq Response . . . . . . . . . . . . . . . 31
8.2. Use of the CA keypair . . 33
5.2.3. GetCertInitial . . . . . . . . . . . . . . . . . 31
8.3. ChallengePassword . . . 33
5.2.3.1. GetCertInitial Response . . . . . . . . . . . . . 33
5.2.4. GetCert . . . . 32
8.4. transactionID . . . . . . . . . . . . . . . . . . . 33
5.2.4.1. GetCert Response . . . . 32
8.5. Unnecessary cryptography . . . . . . . . . . . . . 33
5.2.5. GetCRL . . . . 32
9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 33
10. Normative References
5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 34
5.2.6. GetNextCaCert . . . . . . . . . . . . . 33
Appendix A. Cisco Requester Subject Name Definition . . . . . . . 34
Appendix B. IPSEC Client Enrollment Certificate Request
5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . . 34
Appendix C. Private OID Definitions
6. Contributors/Acknowledgements . . . . . . . . . . . . . . . 36
Appendix D. CRL Query by means of LDAP . 34
7. IANA Considerations . . . . . . . . . . . . . 36
Appendix E. SCEP State Transitions . . . . . . . . 34
8. Security Considerations . . . . . . . 37
Appendix F. . . . . . . . . . . . . 34
8.1. General Security . . . . . . . . . . . . . . . . . . . . . 35
8.2. Use of the CA Capabilities keypair . . . . . . . . . . . . . . . . . . 35
8.3. ChallengePassword . 40

Nourse, et al. Expires July 25, 2009 [Page 3]

Internet-Draft SCEP January 2009

Appendix G. Certificate Renewal . . . . . . . . . . . . . . . . . . . 35
8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 36
8.5. Nonces and CA Replay . . . . . . . . . . . . . . . . . . . . 36
8.6. Key Rollover Usage Issues . . . . . . . . . 41
Appendix H. PKIOperation via HTTP POST Message . . . . . . . . . 41
Authors' Addresses . . . 36
8.7. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 41

Nourse, et al. 36

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 4] 3]

Internet-Draft SCEP January 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.
certification authority. Often there also is a need for protocols to
request a certificate or cert certificate status info, information, although
these functions are often provided by distinct protocols, e.g., LDAP for X509
[RFC4523] or OCSP [RFC2560]. 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 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 described in [RFC2119].

2. The Goal of SCEP encryption
only or signing only. The goal usage of SCEP is any associated certificate can be
restricted by adding key usage and extended key usage attributes to support
the secure issuance of certificates to
network devices in a scalable manner, using existing technology
whenever possible. The protocol supports PKCS#10 [RFC2986]. If key usage is not present, the following operations:

o CA and RA public key distribution

o Certificate enrollment

Nourse, et al.
is assumed to be a general purpose key that may be used for all

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 5] 6]

Internet-Draft SCEP January April 2009

o Certificate query

o CRL query

Certificate and CRL access can be achieved by using

purposes.

2.1.1.1.2. non-RSA Keys

SCEP does not support non-RSA keys. Though the LDAP protocol
(as specified in Appendix D), or by using the query messages defined
in SCEP. The use of HTTP certificate and CRL access, and the support
of CDP as specified in [RFC5280], (being based
on PKCS#7 [RFC2315]) does not preclude them, RSA is outside the scope of this
document. In Section Section 2.1, we first define PKI entity types
as well as the properties of each entity type. In Section
Section 2.2, the PKI operations are described at functional level.
Section Section 2.3 describes only
algorithm supported by current implementations.

2.1.1.1.3. Required Information

A requester MUST have the transaction behavior of each PKI
operations. The complete following information configured before
starting any PKI messages are covered in Section
Section 5.

2.1. SCEP Entity Types

The entity types defined in SCEP are operations:

1. the "requester" type (i.e.,
IPSEC clients), certification authority IP address or fully qualified domain
name,

2. the Certificate Authority (CA) entity type, and certification authority HTTP CGI script path,

3. the
Registration Authority entity type (RA). A requester HTTP proxy information if there is sometimes
called a "SCEP client" in no direct Internet
connection to the following.

2.1.1. Requesters

A requester is server,

4. If CRLs are being published by the CA to an entity whose name is defined in a certificate
subject name field LDAP directory
server, and optionally, in SubjectAltName, a X.509
certificate V3 extension. As a requester, a SCEP client there is
identified by a subject name consisting of the following naming
attributes:

o Fully qualified domain CRL Distribution Point containing only an
X.500 directory name, for example, Router.cisco.com,

o IP Address,

o Serial number, and/or

o x.500 distinguished name.

The then the client will need to know the LDAP
server fully qualified domain name is required for a requester that
intends 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 use configure
multiple trusted certificates. Trusted certificates are configured
as such in the certificate with, for example, IKE [RFC2409]. The
IP address, serial number, and x.500 distinguished name client, based on some out-of-band means such as a
"fingerprint". These trusted certificates are optional used to verify
certificate chains that end in those certificates.

2.1.2. Certification Authority

A certification authority (CA) is an entity whose name attributes.

In the certificate enrollment request, appears in the PKCS#10 [RFC2986] subject
issuer field contains of a certificate.

Before any PKI operations can occur, the required CA generates its own public
key pair and optional name attributes. The
distinguished name, if any, should be the subject name field, while
any domain name, serial number, creates a self-signed CA certificate, or IP causes another
CA to issue a certificate to it.

CA key-rollover and certificate expiry is address supplied should be in
the subjectAltName field. The subjectName field may be empty (if

Nourse, et al. Appendix E.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 6] 7]

Internet-Draft SCEP January April 2009

there is no distinguished name) or the subjectAltName may be omitted,
but not both.

It is important to note that

2.1.2.1. CA Certificate Fingerprint

If a client named as Alice.cisco.com CA certificate is
different than a client named as "Alice.cisco.com+192.0.2.4" (read
Alice.cisco.com plus self-signed and not pre-provisioned on the IP address name attribute 192.0.2.4). From
client, a CA point of view, the Distinguished names assigned in these two
cases are distinct names.

Entity names which are specified as in the IPSEC profile (i.e., FQDN,
IP address and User FQDN) must Certificate fingerprint will be presented in used to authenticate the certificate's
SubjectAltName extension. Multiple IPSEC entity names, (if any) are
encoded as multiple values of a single SubjectAltName extension. The
received CA has the authority to assign a distinguished name to Certificate.

The fingerprint is created by calculating a requester,
whether SHA-1, SHA-256, SHA-512,
or not one was included in the request. The assigned DN
should contain the SCEP client names as MD5 hash on the relative DN.

The attribute identifiers and an example of SCEP client subject name
are specified in Appendix A. Appendix B whole CA certificate. Before any requester can
start its enrollment, this CA certificate has an example from Cisco
VPN Client enrollment request.

2.1.1.1. Local Key/Certificate/CRL Storage 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 Certificate-name
uniqueness

A requester is required apply them to generate, and provide storage for,
asymmetric keypairs. If the requester does not have enough permanent
memory request, possibly
causing the request to save its certificate, then it should be able to query its
own rejected. The requester MUST NOT assume
any of the fields, except for the public key, will be the same in the
resulting certificate from as in the CA 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 an LDAP server, once
answer CRL queries itself, in which case it MUST be online all the
time. The certification authority SHOULD also either answer
certificate
has been issued. queries or make certificates available via LDAP.

2.1.2.4. Name Uniqueness

A keypair can be generated with a specific key usage. The key usage
is conveyed to the CA through MAY enforce the certificate enrollment request.
All current SCEP client implementations expect property that there will be only one keypair key pair for a
given subjectName subject name and key usage combination
and CA, at any given time. This
property is called the certificate-name
uniqueness property, and it implies that a CA that implements SCEP
will enforce the unique mapping between a SCEP client subject name
and its keypairs with a given key usage. At any time, if the subject
name is changed, or if the keypair is updated, the existing certificate would have to be revoked before a name uniqueness property.

2.1.2.5. Retransmission versus new one could be
issued. request

It is desirable that the CA enforce certificate-name uniqueness, but
it is not mandatory. However a 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 or certificate request, nor
certificate. Nor can the second request merely be rejected.

If a client times out from polling for a pending

Nourse, et al. Expires July 25, 2009 [Page 7]

Internet-Draft SCEP January 2009 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 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 time 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 time period of an existing certificate for the same subjectName 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.1.3. 2.1.2.6.3. See also
Appendix G.

2.1.1.2. 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" "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 ChallengePassword PKCS#9 [RFC2985]
challengePassword attribute to be sent as part of the enrollment
request. SCEP uses this
ChallengePassword challengePassword to satisfy the above
requirements for security. The PKCS#7 [RFC2315] envelope protects
the privacy of the challenge password.

2.1.1.2.1.

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

Nourse, et al. Expires July 25, 2009 [Page 8]

Internet-Draft SCEP January 2009

2.1.1.2.2.

2.1.2.6.2. Automated enrollment authentication

When utilizing a pre-shared secret scheme, the server should MAY distribute
a shared secret to the requester requester, which can will uniquely associate the
enrollment request with the given end entity. 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 MUST enter the
pre-distributed secret as the ChallengePassword. It can then challengePassword.

The pre-shared secret MAY also be used to authenticate a request for
the certificate's revocation.

2.1.1.3. Requester Uses

2.1.2.6.3. Existing CA-Issued or Self-Signed Certificates

In this protocol, the communication between the requester and the
certificate
certification authority is secured by using PKCS#7 [RFC2315] as the
messaging protocol (see Section 4). 3). PKCS#7 [RFC2315], however, is a
data format which assumes the communicating entities already possess
the peer's certificates and requires both parties use the issuer
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, 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, that certificate MAY be
presented as credentials instead of a self-signed certificate.
Policy settings on the SCEP server will determine if the request
can be accepted or not.

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 subjectName as in
the pkcs10 request.

During the certificate enrollment, the requester will attach the
appropriate certificate to the signed certificate request.

When the Certificate Authority creates the PKCS#7 envelope on the
issued certificate, it should use the public key, issuer name, and
serial number conveyed in the above included certificate (from the
SignerInfo section of the inner pkcs#7 of the request). This will

Nourse, et al. Expires July 25, 2009 [Page 9]

Internet-Draft SCEP January 2009

inform the end entity on which private key should be used to open the
envelope. Note that when a client enrolls for separate encryption peer's certificates and signature certificates, it may requires that both parties use the signature certificate to
sign both requests,
subject names and then expect its signature key to be used issuer assigned certificate serial numbers to
encrypt both responses.

In any case,
identify the recipientInfo on certificate in order to verify the envelope should reflect signature and decrypt
the key
used to encrypt message.

o If the request.

2.1.1.4. Trusted CA Store

To support interoperability between IPSEC peers whose certificates
are requesting system already has a certificate issued by different CAs, SCEP allows the users to configure
multiple trusted certificates. Trusted certificates are configured
as such in
CA, and the client, based on some out-of-band means such as a
"fingerprint". These trusted certificates are used to verify
certificate chains CA supports RENEWAL (see Appendix D), that end in those certificates.

2.1.2. Certificate Authority

A Certificate Authority(CA) is an entity whose name is defined in certificate
SHOULD be presented as credentials for the renewal of that
certificate issuer name field. Before any PKI operations can begin, if the CA generates its own public key pair supports the "Renewal" capability and creates a self-signed CA
certificate, or causes another the CA to issue a
policy permits the certificate to it.
Associated with 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 fingerprint which will self-signed certificate MUST be used by instead.
The self-signed certificate MUST use the requester to authenticate same subject name as in
the PKCS#10 request.

During the received CA certificate if
it is self-signed. The fingerprint is created by calculating a
SHA-1, SHA-256, SHA-512, or MD5 hash on enrollment, the whole CA certificate.
Before any requester can start its enrollment, this CA MUST use the
appropriate certificate
has to be configured at sign the entity side securely. For IPSEC clients, PKCS#7 [RFC2315] (see Section 3).

When the client certificates must have SubjectAltName extension. To
utilize LDAP as a CRL query protocol, certification authority creates the certificates must have a
CRL Distribution Point. Key usage is optional. Without key usage, PKCS#7 [RFC2315]
envelope on the public key is assumed as a general purpose public key and issued certificate, it can
be used for all purposes.

A Certificate Authority may enforce certain name policy. When using
a X.500 directory name as SHOULD use the subject public key,
issuer name, all the name attributes
specified and serial number conveyed in the PKCS#10 [RFC2986] request should be above included as
Relative DN. All
certificate. This will inform the name attributes as defined in [RFC5280] end entity of which private key
should be specified in used to open the SubjectAltName. An example is provided in
Appendix A.

If there is no LDAP or HTTP query protocol support, envelope.

Note that when a client enrolls for separate encryption and signature
certificates, it may use the Certificate
Authority itself should answer signature certificate to sign both
requests, and CRL queries, and then expect its signature key to
this end it should be online all the time.

The updating of the CA's public key is addressed in Appendix G.

Nourse, et al. used to encrypt

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 10]

Internet-Draft SCEP January 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 Authorities Authority

In an environment where an RA a Registration Authority (RA) is present, a
requester performs enrollment through the RA. In order to setup a secure channel securely
communicate with an RA using PKCS#7 [RFC2315], the RA certificate(s) have to be
obtained by the client in addition to the CA certificate(s).

In the following, the CA and RA are specified as one entity in MUST use
the
context of PKI operation definitions.

2.2. SCEP Operations Overview

In this section, we give a high level overview RA's keys instead of the PKI operations
as defined in SCEP.

2.2.1. Requester Initialization CA's keys. The requester initialization includes the key pair generation and the
configuring of the required information RA certificate(s) (in
addition to communicate with the
certificate authority.

2.2.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 CA certificate) will be restricted by adding key usage and extended key usage attributes
to the PKCS#10 [RFC2986].

2.2.1.2. non-RSA Keys

SCEP does not support non-RSA keys. Though the protocol (being based
on PKCS#7) does not preclude them, RSA is the only algorithm
supported by current implementations.

2.2.1.3. Required Information

A requester is required to have the following information configured
before starting any PKI operations:

1. the certificate authority IP address or fully-qualified domain
name,

2. the certificate authority HTTP CGI script path,

Nourse, et al. Expires July 25, 2009 [Page 11]

Internet-Draft SCEP January 2009

3. returned in the HTTP proxy information if there is no direct Internet
connection to GetCaCert
Response (see Section 5.2.1.1.2) automatically.

Clients MUST verify the server,

4. If CRLs are being published authorization of the RA certificates. The
authorization mechanism is specified by the CA to an LDAP directory
server, administrator and there is a CRL Distribution Point containing only an
X.500 directory name, then
out of scope for this document.

In the client will need to know following, the LDAP
server fully-qualified domain name or IP address. CRL
Distribution Points CA and RA are discussed in more detail specified as one entity in [RFC5280].

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

Before

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, the requester needs to get
the CA/RA certificates. At this time, since
started.

Since no public key has yet been exchanged between the requester and
the CA/RA, the message to get the
CA/RA certificate messages cannot be secured using PKCS#7 [RFC2315]. Instead, [RFC2315], and
the CA/RA certificate distribution data is implemented as instead transferred in the clear.

If an RA is in use, a clear HTTP Get
operation. 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 has to MUST authenticate the
CA certificate by comparing the finger print 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.

This operation is defined as a transaction consisting of one HTTP Get
message and one HTTP Response message:
REQUESTER CA SERVER
Get CA/RA Certificate: HTTP Get message
----------------------------->
CA/RA Certificate download: HTTP Response message
<---------------------------------------
Compute finger print and
call CA operator.
Receive call and check finger print

Get CA/RA Certificate

If an RA is in use,

Nourse & Vilhuber Expires October 3, 2009 [Page 11]

Internet-Draft SCEP April 2009

Because a degenerated PKCS#7 [RFC2315] with long time can pass between queries from a certificate
chain consisting of both RA requester to a
CA/RA and CA because RA certificates can change at any time, it is sent back to the
end entity. Otherwise
recommended that a requester not store RA certificates. Instead, the CA certificate is directly sent back as
requester SHOULD retrieve the HTTP response payload.

2.2.3. 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 [RFC2315]. After (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 receives returns a CertRep (Section 3.2.2) message with status
set to PENDING, the
request, it 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 either automatically approve 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 request and 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

Figure 1: State Transition Diagram

Certificate enrollment starts at the state CERT-NONEXISTANT.

Sending a PKCSReq message changes the certificate back, state to CERT-REQ-PENDING. If
there is no response, or it will require sending is not possible, the requester state reverts
back to wait until
the operator can manually authenticate the identity of CERT-NONEXISTANT.

Receiving a CertRep message with pkiStatus set to SUCCESS changes the requester.

Nourse, et al. Expires July 25, 2009 [Page 12]

Internet-Draft SCEP January 2009

In
state to CERT-ISSUED.

Receiving a CertRep message with pkiStatus set to FAILURE changes the automatic mode,
state to CERT-NONEXISTANT.

If the transaction consists of one PKCSReq PKI
Message, and one server sends back a CertRep PKI message.

In the manual mode, message with pkiStatus set to
PENDING, the requester enters into will keep polling mode by
periodically sending a GetCertInitial PKI
message to the server, until either a CertRep message with status set
to SUCCESS is received, or the server operator completes maximum number of polls has been
exceeded.

If the manual authentication, after
which maximum number of polls has been exceeded or a CertRep message
with pkiStatus set to FAILURE is received while in the CA CERT-REQ-
PENDING state, the end entity will respond transition to GetCertInitial by returning the issued
certificate. CERT-NONEXISTANT
state, and the SCEP client can eventually initiate another enrollment
request. It is up important to local CA policy (and CA implementation) note that, as to whether a
certificate is granted automatically, long as the requester does
not change its subject name or whether it is manually
granted by keys, the administrator. The ChallengePassword MAY same transaction ID will be
used to
automatically authenticate in the request, but does not have to.

Polling mode "new" transaction. This is entered whenever important because based on
this transaction ID, the server returns certification authority can recognize this
as an existing transaction instead of a PENDING
response.

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

The

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

GetCertInitial: polling msg
--------------------------------> CertRep: pkiStatus = SUCCESS
certificate attached
<------------------------------
Receive issued certificate.

2.2.4. Requester 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 ChallengePassword (which
has been sent to the server as an attribute of the PKCS#10 [RFC2986]

Nourse, et al. Expires July 25, 2009 [Page 13]

Internet-Draft SCEP January 2009

certificate request). If the ChallengePassword matches, the
certificate can be revoked.

2.2.5.

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
understand
understands the LDAP scheme supported by the CA. The SCEP client
assumes that the subject DN name 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 certificate certification authority, a requester
sends a request consisting of the certificate's issuer name and the
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 PKI (Section 3.2.4) message and one
CertRep PKI
message: (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.

2.2.6.

Figure 4: GetCert Transaction

2.2.4. CRL Distribution 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 query 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. This is the preferred method. Please
refer to Appendix D for the examples of CRL Distribution Point.

2. If the CA does not support CDP's, a CRL query is composed by
creating a message consisting of the CA issuer subject name and the CA's
certificate serial number.
number of the certification authority's certificate. This method
is deprecated because

* it does not scale well and

* requires the CA to be a high-availability
service. 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

Nourse, et al. Expires July 25, 2009 [Page 14]

Internet-Draft SCEP January 2009
requests: The transaction to query retrieve a CRL consists of one GetCRL
PKI message and one CertRep PKI message message, which contain 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 CRL (no
certificates).

REQUESTER CA SERVER
GetCRL: PKI CRL query msg
---------------------------------->
CertRep: CRL attached
<-------------------------------- 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 certificate 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 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 same requester, checking of the keys must be different.

2.3.2. State Transitions in Certificate Enrollment

The requester state transitions during enrollment operation are
indicated CA fingerprint, as specified in
Section 2.1.2, and the diagram below:

Nourse, et al. Expires July 25, 2009 [Page 15]

Internet-Draft SCEP January 2009

As described pre-shared secret
authentication, as specified in Section 2.1.2.6. The third goal is
met through the section 2.2.3, certificate enrollment starts at
the state CERT-NONEXISTANT. Sending PKCSReq changes the state to
CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes use of a challenge password for revocation, which is
chosen by the
state SCEP client and communicated to CERT-ISSUED. In the case CA protected by the server sending back
PKCS#7 [RFC2315] encryptedData, as specified in Section 2.2.5.

The motivation of the
response with pending status, first security goal is straightforward. The
motivation for the requester will keep polling
certificate response by sending GetCertInitial second security goal is to protect the server, until
either identity
information in the enrollment requests and certificates. For
example, two IPSEC hosts behind a CertRep firewall may need to exchange
certificates, and may need to enroll certificates with SUCCESS status a CA that is received, or the maximum
polling number has been exceeded.

If an error or timeout occurs in
outside of a firewall.

Most networks with firewalls seek to prevent IP addresses and DNS
information from the CERT-REQ-PENDING state, trusted network leaving that network. The
second goal enables the end
entity will transition hosts in this example to enroll with a CA
outside the CERT-NONEXISTANT state. firewall without revealing this information. The client administrator will, eventually, start up another
enrollment request. It
motivation for the third security goal is important to note that, as long as the
requester does not change its subject name or keys, protect the same
transaction id will 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 used 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 "new" transaction. This SCEP message is
important because based on this transaction id, protected both for the certificate
authority server can recognize this as an existing transaction
instead of a new one.

2.3.3. Transaction Behavior integrity
of Certificate/CRL Access

There is no state maintained during certificate access its end-to-end transaction information and CRL access
transaction. When using the certificate query and CRL query messages
defined in confidentiality of
its information portion. The advantage of this protocol, technique over the
conventional transaction identifier message format is still
required so that the requester can match signed
transaction type information and the response message with status of the upstanding request message. When using LDAP transaction can be
determined prior to invoking security handling procedures specific to query the
certificate and the CRL,
the behavior is specified by information portion being processed.

Some messages do not require enveloping, in which case the LDAP
protocol.

2.4. Security
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 security goals of SCEP are that no adversary can:

Nourse, et al. 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 July 25, October 3, 2009 [Page 16] 18]

Internet-Draft SCEP January April 2009

o subvert the public key/identity binding from that intended,

o discover the identity information

pkcsPKIEnvelope (Section 3.1.2).

When a particular SCEP message carries data, this data is carried in
the enrollment requests and
issued certificates,

o cause the revocation messageData.

Note: The remainder of certificates with any non-negligible
probability.

Here an adversary this document will refer only to
'messageData', but it is any entity other than the requester and understood to always be encapsulated in the CA
(and optionally
pkcsPKIEnvelope (Section 3.1.2). The format of the RA) participating data in the protocol that
messageData 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 defined by the implementer's choice messageType attribute (see
Section 3.1.1) of
cryptographic hash functions and ciphers. The required algorithms
are RSA, DES and MD5. Depending on the CA Capabilities, Triple-DES
may SignedData. If there is no messageData to be used instead of DES, and SHA-1, SHA-256, or SHA-512 may
transmitted, the entire pkcsPKIEnvelope MUST be
used instead of MD5. [See Appendix F]. omitted.

3.1. SCEP pkiMessage

The first and second goals are met through basic building block of all secured SCEP messages is the use 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 PKCS#10 [RFC2986] encryption PENDING CertRep
messages will lack any signed content), MUST be a pkcsPKIEnvelope
(Section 3.1.2), and digital signatures
using authenticated public keys. The CA's public key is
authenticated via must match the checking messageType attribute.

o The SignerInfo MUST contain a set of the CA fingerprint, authenticatedAttributes (see
PKCS#7 [RFC2315] Section 9.2 as well as specified in Section 2.1.2, and the 3.1.1 in this
document). All messages MUST contain

* an SCEP client's public key 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
through the manual authentication or pre-shared secret
authentication,
attributes, and are carried, as specified in PKCS#7 [RFC2315] Section 2.1.1.2. The third goal is
met through
9.2, in the use of a Challenge Password SignerInfo for revocation, that is
chosen by the SCEP client and communicated this signedData.

Please refer to Appendix B for the CA protected by the
PKCS#7 [RFC2315] encryption, OID definitions.

Transaction Attributes

The motivation of attributes are detailed in the first security goal following sections.

3.1.1.1. transactionID

The transactionID is straightforward. an attribute that uniquely identifies a
transaction. This attribute MUST be included in all PKI messages.

The
motivation for transactionID SHOULD be the second security goal is to protect MD5 hash of the identity
information in public key from the enrollment requests and certificates. For
example, two IPSEC hosts behind
request, encoded as a firewall may need to exchange
certificates, and may need PrintableString. The transactionID MUST be
unique to enroll certificates with a CA given public key, so that is
outside of a firewall.

Most networks with firewalls seek to prevent IP addresses and DNS
information from any new requests for
certificates using the trusted network leaving that network. The
second goal enables same key can be detected as duplicates by the hosts in this
server (see Section 8.4).

For a non-enrollment message (for example to enroll with GetCert and GetCRL), the
transactionID SHOULD be a CA
outside number unique to the firewall without revealing this information. client.

3.1.1.2. messageType

The
motivation for the third security goal is to protect messageType attribute specifies the SCEP clients
from denial type of service attacks.

3. Transport Protocol

In the SCEP protocol, HTTP is used as the transport protocol for operation performed
by the transaction. This attribute MUST be included in all PKI
messages.

Nourse, et al. 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 July 25, October 3, 2009 [Page 17] 20]

Internet-Draft SCEP January April 2009

3.1. HTTP "GET" and "POST" Message Format

The following is the syntax definition of a HTTP GET message sent
from a requester to

o GetCertInitial (20) -- Certificate polling in manual enrollment

o GetCert (21) -- Retrieve a certificate authority server:

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

where:

o CGI-PATH defines the actual CGI path to invoke the CGI program GetCRL (22) -- Retrieve a CRL

3.1.1.3. pkiStatus

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

o CGI-PROG SUCCESS (0) -- request granted

o FAILURE (2) -- request rejected. When pkiStatus is set to be FAILURE, the string "pkiclient.exe". This is
intended to
failInfo attribute, as defined in Section 3.1.1.4, MUST also 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.
present.

o OPERATION is set to be PENDING (3) -- request pending for manual approval

3.1.1.4. failInfo

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

* "PKIOperation" when the GET message carries a PKI message to
request certificates badAlg (0) -- Unrecognized or CRL

* "GetCACaps", "GetCACert", "GetNextCACert" unsupported algorithm identifier

o badMessageCheck (1) -- integrity check failed

o badRequest (2) -- transaction not permitted or "GetCACertChain"
when supported

o badTime (3) -- The signingTime attribute from the GET operation is used PKCS#7
SignedAttributes was not sufficiently close to get CA capabilities, CA/RA
certificate, the replacement CA/RA certificates for when the
current ones expire, or the CA Certificate chain (respectively)

o MESSAGE is system time
(see Section 3.1.1.6).

* a base64-encoded PKI message , when OPERATION is "PKIOperation" badCertId (4) -- No certificate could be identified matching the
provided criteria

3.1.1.5. senderNonce and method is GET.

* responderNonce

The attributes of senderNonce and recipientNonce are 16 byte random
numbers generated for each transaction to prevent replay attacks.

When a CRL distribution point in URI format , when OPERATION is
GetCRL,

* requester sends a string which represents the certificate authority issuer
identifier otherwise.

SCEP uses the HTTP "GET" and "POST" messages PKI message to request information
from the CA. Requests for CA certificates or capabilities are sent server, a senderNonce
MUST be included in the clear, using "GET", with the OPERATION and MESSAGE fields
identifying message.

The responder SHOULD copy the requested data. CRLs may also be requested in senderNonce into the
clear if recipientNonce of
the CA supports it.

Nourse, et al. reply as a proof of liveliness.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 18] 21]

Internet-Draft SCEP January April 2009

Other types of requests are sent using

The requester SHOULD verify that the PKCS#7 [RFC2315] data
format. These may be issued by means recipientNonce of a GET operation with
OPERATION and MESSAGE parameters in the Request-URL. OPERATION
identifies reply
matches the type of GET operation, senderNonce it sent in the request.

3.1.1.6. signingTime Attribute

The signingTime Attribute is defined in [RFC2985] Section 5.3.3, and MESSAGE
is actually the
PKCS#7 [RFC2315] message Base64-Encoded.

For example. carried as defined in a requester may submit [RFC2315] authenticated attribute (Section
9.2). This attribute is optional.

3.1.2. SCEP pkcsPKIEnvelope

The information portion of a SCEP message via HTTP to the server is carried inside an
enveloped-data content type, as follows:
GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0

If supported by the CA, defined in PKCS#7 [RFC2315] Section
10, with the message may also following restrictions:

o version MUST be sent via HTTP POST:
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0
Content-Length: 1234

This is further described 0

o contentType in Appendix H. To determine if the CA
supports POST, use the GetCACaps message described encryptedContentInfo MUST be data ({pkcs-7 1}) as
defined in Appendix F.

3.2. Response Message Format

For each GET operation, PKCS#7 [RFC2315] Section 8.

o encryptedContent MUST be the CA/RA server will return a MIME object
via HTTP. For a GET operation with PKIOperation as its type, SCEP message being transported (see
Section 4), and must match the
response is tagged as having a Content Type of application/
x-pki-message. messageType signedAttribute in the
pkiMessage.

The body of this message is a BER encoded binary PKI
message. The following is an example of the response:
"Content-Type:application/x-pki-message\n\n"<BER-encoded PKI msg>

In encrypted using the case public key of GET operation with a type the recipient of GetCACert the MIME
content type returned will depend on whether or not an
message, i.e. the RA is in use.
If there is no RA, only or the CA certificate is public key (if sent back in the
response, and from the response has
requester), or the content type tagged requester public key (if sent as
application/x-x509-ca-cert. The body of the response is a DER
encoded binary X.509 certificate. For example:
"Content-Type:application/x-x509-ca-cert\n\n"<BER-encoded X509>

If there is an RA, reply to the RA certificates are sent back together with
requester).

3.2. SCEP pkiMessage types

All of the CA certificates, a certificate-only PKCS#7 [RFC2315] SignedData
is sent back messages in the response this section are pkiMessages (Section 3.1),
where the SignerInfo is empty. Section
5 has the detailed definition type of the message format MUST be specified in this case.
The content type is application/x-x509-ca-ra-cert.

The response to GetNextCACert is always a certificates-only PKCS#7
[RFC2315] SignedData with the 'messageType'
Signed Attribute. Each section defines a content 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 application/
x-x509-ca-ra-cert. If there is an RA, a DER-encoded PKCS#10
Certification Request [RFC2986]. The signer is certification request MAY
contain any fields defined in PKCS#10 [RFC2986], and MUST contain at
least the current RA
certificate. Otherwise, following items:

o the signer is subject Distinguished Name

o the current CA certificate.

Nourse, et al. subject public key

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 19] 22]

Internet-Draft SCEP January 2009

If the CA supports it, PKIOperation may also be done via an HTTP
POST. This is described in Appendix H.

4. Secure Transportation: PKCS#7

PKCS#7 [RFC2315] is April 2009

o a general enveloping mechanism that enables both
signed and encrypted transmission of arbitrary data. It is widely
implemented and included 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 RSA tool kit. issued certificate.

In this section, addition to the
general PKCS#7 [RFC2315] enveloped PKI message format is specified.

All messages MUST be authenticatedAttributes required for a valid
PKCS#7 [RFC2315] structures, unless
otherwise noted.

4.1. SCEP Message Format

An SCEP [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 an information portion (which a DER-encoded degenerate
certificates-only Signed-data (Section 3.3). The exact contents
required for certain CertRep replies depends on the type of SCEP request
this message being sent) and is a set of transaction-
specific Attributes (see section Section 4.2).

The message-specific information reply to and is used as EnvelopeContent detailed in Table 1 and in an
SCEP pkcsPKIEnvelope message (see section
Section 4.1.1).

Next, 4.

In addition to the pkcsPKIEnvelope is used as Content authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage SCEP
type (see section Section 4.1.2).

The transaction-specific attributes MUST include the following
attributes:

o the transactionID (Section 3.1.1.1) attribute copied from the
request we are encoded as responding to

o a messageType (Section 3.1.1.2) attribute set of
authenticatedAttributes in the SignerInfo of the SignedData.

By applying both enveloping and signing transformations, to CertRep

o a SCEP
message is protected both for the integrity of its end-end-transition
information and the confidentiality of its information portion. The
advantage of this technique over senderNonce (Section 3.1.1.5) attribute

o a recipientNonce attribute (Section 3.1.1.5) copied from the conventional transaction message
format is that,
senderNonce from the signed transaction type information and request we are responding to.

o a pkiStatus (Section 3.1.1.3) set to the status of the transaction can reply.

The pkcsPKIEnvelope of a CertRep (if present), MUST be determined prior to invoke security
handling procedures specific encrypted with
the same certificate used to sign the information portion being
processed.

4.1.1. SCEP pkcsPKIEnvelope

The SCEP messages are carried inside an Enveloped-data content type,
as defined PKCSReq this message is a reply
to, according to section 10 in PKCS#7 Section 10, with [RFC2315]. This means that if
a self-signed certificate was used to send the following restrictions:

o version shall be 0

o EncryptedContent shall request, this self-
signed certificate will be reflected in the SCEP message being transported (see recipientInfo field of
the envelopedData, in accordance with PKCS#7 [RFC2315] section Section 5)

Nourse, et al. 10.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 20] 23]

Internet-Draft SCEP January April 2009

The message is encrypted using the public key of the recipient, i.e.
the RA or

3.2.2.1. CertRep SUCCESS

When the CA pkiStatus attribute is set to SUCCESS, the messageData for
this message is for.

NOTE: The PKCS#7 [RFC2315] EncryptedContent is specified as an octet
string, but SCEP entities must also accept a sequence of octet
strings as a valid alternate encoding.

4.1.2. SCEP pkiMessage type

A SCEP pkiMessage consists of an Signed-data content type, as defined
in PKCS#7 Section 9. The following restrictions apply:

o version shall be 1

o The signed content shall be a pkcsPKIEnvelope

o DER-encoded degenerate certificates-only
Signed-data (Section 3.3). The SignerInfo MUST contain a set contents of authenticatedAttributes (see
PKCS#7 Section 9.2 as well as section Section 4.2 in this
document. All messages are required to contain a SCEP
transactionID attribute, an SCEP messageType, and, of course, any
attributes required by PKCS#7 section 9.2. It may have other
attributes as well, depending degenerate
certificatess-only Signed-Data depends on what the original request
was, as outlined in Table 1.

The message is signed in one reply MUST contain at least the issued |
| | certificate attached to the certificates field |
| | of two ways: the Signed-Data. The requester can generate
a self-signed certificate, or reply MAY contain |
| | additional certificates, but the requester can use a previously issued certificate, if |
| | certificate MUST be the RA/CA supports first in the RENEWAL option.

4.2. Signed Transaction Attributes list. The following transaction attributes are encoded as authenticated
attributes, and are carried, |
| | reply MUST NOT contain any CRL's. All returned |
| | certificates MUST conform to [RFC5280]. |
| GetCertInitial | same as specified in PKCS#7 Section 9.2, in PKCSReq |
| GetCert | the SignerInfo for this signedData.

Please refer reply MUST contain at least the requested |
| | certificate attached to Appendix B for the OID definitions.

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 attributes are detailed in pkcsPKIEnvelope
(Section 3.1.2) MUST be omitted.

3.2.2.3. CertRep PENDING

When the following sections.

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

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 21] 24]

Internet-Draft SCEP January April 2009

4.2.1. transactionID

3.2.3. GetCertInitial

The transactionID is an attribute which uniquely identifies messageData for this type consists of a
transaction. This attribute DER-encoded
IssuerAndSubject (Section 3.2.3.1). The issuer is required in all PKI messages.

Because the enrollment transaction could be interrupted by various
errors, including network connection errors or client reboot, set to the
SCEP client generates a transaction identifier by calculating a hash
on
issuerName from the public key value for certification authority from which the enrollment we are issued
certificates. The Subject is requested. This
retains set to the same transaction identifier throughout SubjectName we used when
requesting the enrollment
transaction, even if certificate.

In addition to the client has rebooted or timed out, and issues
a new enrollment request authenticatedAttributes required for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the same key pair.

It also provides the way for following
attributes:

o the CA same transactionID (Section 3.1.1.1) attribute from original
PKCSReq message

o a messageType (Section 3.1.1.2) attribute set to uniquely identify GetCertInitial

o a
transaction in its database. At senderNonce (Section 3.1.1.5) attribute

3.2.3.1. IssuerAndSubject

Similar to the requester side, it generates a
transaction identifier which is included IssuerAndSerial defined in PKCSReq. If the CA
returns a response PKCS#7 [RFC2315] Section
6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7).

The ASN.1 definition of PENDING, the requester will poll by
periodically sending out GetCertInitial with the same transaction
identifier until either a response other than PENDING issuerAndSubject type is obtained, or 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 configured maximum time has elapsed.

For non-enrollment message (for example GetCert "distinguished name of the certificate issuer and GetCRL), an issuer-
specific certificate serial number" which uniquely identifies the
transactionID should be a number unique
certificate we are requesting.

In addition to the client.

4.2.2. messageType

The messageType attribute specify the type of operation performed by
the transaction. This attribute is authenticatedAttributes required in all PKI messages.
Currently, for a valid
PKCS#7 [RFC2315], this pkiMessage MUST include the following message types are defined:

o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request

o CertRep (3) -- Response to certificate or CRL request

o GetCertInitial (20) -- Certificate polling in manual enrollment
attributes:

o GetCert (21) -- Retrieve a certificate transactionID (Section 3.1.1.1) attribute

o GetCRL (22) -- Retrieve a CRL

4.2.3. pkiStatus

All response message will include transaction status information
which is defined as pkiStatus attribute:

o SUCCESS (0) -- request granted

Nourse, et al. messageType (Section 3.1.1.2) attribute set to PKCSReq

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 22] 25]

Internet-Draft SCEP January April 2009

o FAILURE (2) -- request rejected. This also requires a failInfo 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 present,
included in the signed envelope.

3.2.5. GetCRL

The messageData for this type consists of a DER-encoded
IssuerAndSerial as defined in section 4.2.4.

o PENDING (3) -- request pending for manual approval

4.2.4. failInfo PKCS#7 [RFC2315] Section 6.7. The failInfo attribute will contain one
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 failure
reasons:

o badAlg (0) -- Unrecognized or unsupported algorithm ident

o badMessageCheck (1) -- integrity check failed
attributes:

o badRequest (2) -- transaction not permitted or supported a transactionID (Section 3.1.1.1) attribute

o badTime (3) -- Message time field was not sufficiently close a messageType (Section 3.1.1.2) attribute set to
the system time PKCSReq

o badCertId (4) -- No certificate could be identified matching the
provided criteria

4.2.5. a senderNonce and responderNonce (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 attributes use of senderNonce such a
degenerate case is to disseminate certificates and recipientNonce are the 16 byte
random numbers generated 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 each transaction to prevent SCEP the replay
attack.

When a requester sends ContentInfo of a PKI message to
degenerate certificates-only Signed-Data MUST be empty.

When carrying certificates, the server, a senderNonce is
included in certificates are attached to the message. After
'certificates' field of the server processes Signed-Data. When carrying a CRL, the request, it
CRL will send back the requester senderNonce as be attached to the recipientNonce and
generates another nonce as 'crls' field of the senderNonce in Signed-Data.

4. SCEP Transactions

This section describes the response message.
Because SCEP Transactions, without explaining the proposed PKI protocol is a two-way communication
protocol, it
transport. The transport of each message is clear that the nonce can only be used by discussed in Section 5.
Some of the
requester transaction-requests have no data to prevent send, i.e. the replay. The server has to employ extra
state related information to prevent only
data is the message-type itself (e.g. a replay attack. 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 Transaction Specification April 2009

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

5.1. Certificate Enrollment

The certificate enrollment transaction consists order of one PKCSReq
message sent to the certificate authority from a requester, transactions in this section is mirrored in
Section 5.2 for better organization and one
CertRep message sent back from readability.

4.1. Get CA Certificate

To get the server.

Nourse, et al. Expires July 25, 2009 [Page 23]

Internet-Draft SCEP January 2009

Precondition: Both CA certificate(s), the requester and sends a GetCACert message
to the certificate authority have
completed their initialization process. The requester has already
been configured 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 CA/RA responding server has RA
certificates or only a single CA certificate.

Postcondition: Either 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,
or requester (regardless of
the end entity presence of RA certificates), a fingerprint is notified to do generated using
the manual authentication, SHA1, SHA256, SHA512 or MD5 hash algorithm on the
request is rejected.

5.1.1. PKCSReq Message Format

A PKCSReq message is a pkiMessage (see section Section 4.1.2), with
the messageType attribute set to PKCSReq.

The information portion of whole CA
certificate. If the pkiMessage is requester does not have a PKCS#10 [RFC2986] certificate request, which MUST contain at least the following items:

o the subject Distinguished Name

o the subject public key

o path to a ChallengePassword attribute. The Challenge Password
trusted CA certificate, this fingerprint may be used to (out-of-band) authenticate verify the enrollment request itself, or in
an
certificate, by some positive out-of-band revocation request for the issued certificate.

Of course means, such as a phone call
or pre-provisioning.

4.1.1.1. CA Certificate Response Message Format

If the certificate request may also contain any additional
fields that make up server is a valid PKCS#10 request, including but certification authority and does not
limited to an ExtensionReq attribute which is have any RA
Certificates, the response consists of a sequence 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
extensions a DER-
encoded degenerate certificates-only Signed-data (Section 3.3)
containing the requester expects to be included in its V3 CA certificate
extensions (for example key-usage and extended key-usages).

This pkiMessage of type PKCSReq MUST contain:

o RA certificates.

4.2. Certificate Enrollment

A transactionID attribute, calculated as per section Section 4.2.1

o a messageType attribute set to PKCSReq

o a senderNonce, calculated as per section Section 4.2.5

The pkiMessage is then encrypted into a pkcsPKIEnvelope (Section 3.2.1) message (see
section Section 4.1.1).

5.1.2. CertRep Message Format

The response is used to an SCEP perform a certificate
enrollment request (PKCSReq) is transaction.

The reply MUST be a CertRep
message.

If the request is granted, (Section 3.2.2) message sent back from
the pkiStatus is set to server, indicating SUCCESS, and the
certificate is returned.

Nourse, et al. FAILURE, or PENDING.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 24] 27]

Internet-Draft SCEP January April 2009

If the request is rejected,

Precondition: Both the pkiStatus is set to FAILURE, requester and a
failInfo attribute is returned.

If the server requires manual approval of the request, certification authority have
completed their initialization process. The requester has already
been configured with the pkiStatus
is set to PENDING.

5.1.2.1. PENDING Response

When CA/RA certificate.

Postcondition: Either the CA certificate is configured to manually authenticate received by the requester,
or the
CertRep is returned with the attribute pkiStatus set to PENDING. The
data portion for this message end entity is null. In addition notified to do the attributes
required by PKCS#7, the following SCEP attributes are required:

o messageType set to CertReq

o transactionID copied from manual authentication, or the PKCSReq
request is rejected.

4.2.1. Certificate Enrollment Response Message

If the request is granted, a CertRep (Section 3.2.2) message

o with
pkiStatus set to PENDING

o senderNonce as defined in section Section 4.2.5

o recipientNonce as defined in section Section 4.2.5

5.1.2.2. FAILURE Response

In this case, SUCCESS is returned. The reply MUST also contain
the CertRep sent back to certificate (and MAY contain any other certificates needed by the requester is same as
requester). The issued certificate MUST be the first in the PENDING case, except that list.

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

5.1.2.3. SUCCESS response

In this case, attribute.

If the information portion of CertRep will be a
degenerated PKCS#7 [RFC2315] which contains the requester's newly
generated certificate. The CertRep CA is otherwise identical configured to manually authenticate the
PENDING reply, requester, a
CertRep (Section 3.2.2) message with the exception that pkiStatus is set to SUCCESS.

5.2. PENDING is
returned..

4.3. Poll for Requester Initial Certificate

Either triggered by the PENDING status received from the CertRep, or

Triggered by the non-response timeout for the previous PKCSReq, 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.

Nourse, et al. Expires July 25, 2009 [Page 25]

Internet-Draft SCEP January 2009 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.

5.2.1. GetCertInitial Message Format

Since at this time the certificate has not been issued, the requester
can only use the requester's subject name (which was contained in the
original PKCS#10 sent via PKCSReq), combined with the transactionID
attribute, to identify the polled certificate request.

The certificate authority server must be able to uniquely identify
the polled certificate request. A subject name can have more than
one outstanding certificate request (with different key usage
attributes).

The content of the pkiMessage with messageType GetCertInitial is an
ASN.1 issuerAndSubject type (see figure Figure 1).

In addition to the authenticatedAttributes required for a valid
PKCS#7, the pkiMessage MUST include the following:

o messageType set to GetCertInitial

o transactionID

o senderNonce

issuerAndSubject
issuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name
}

Figure 1

5.2.2. GetCertInitial

4.3.1. Polling Response Message Format

The response messages for GetCertInitial are the same as for PKCSReq.

5.3. in
Section 4.2.1.

4.4. Certificate Access

The certificate query message defined in this section is an option when the LDAP server is
not available to provide the certificate

Nourse, et al. Expires July 25, 2009 [Page 26]

Internet-Draft SCEP January 2009 query. A requester should
be able to query an issued certificate from the certificate 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 message sent back from the server.

PreCondition: The queried certificate have been issued by the
certificate authority and the issuer assigned serial number is known.

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

5.3.1. GetCert Message Format

The queried certificate is identified by its issuer name and the
issuer assigned serial number. If this is a query for an arbitrary
requester's certificate, the requesting requester should includes its
own CA issued certificate in the signed envelope. 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 server by a requester, and one CertRep (Section 3.2.2) message
sent back from the self-signed server.

PreCondition: The queried certificate has to be included in have been issued by the signed envelope.

The content of
certification authority and the pkiMessage with messageType GetCert issuer assigned serial number is an ASN.1
IssuerAndSerial type, as specified in PKCS#7 Section 6.7.

In addition to the authenticatedAttributes required for a valid
PKCS#7,
known.

PostCondition: Either the pkiMessage MUST include certificate is sent back or the following:

o messageType set to GetCert

o transactionID

o senderNonce

5.3.2. CertRep request is
rejected.

4.4.1. Certificate Access Response Message Format

In this case, the CertRep from the server is same as the CertRep for
the PKCSReq, 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

Nourse, et al. Expires July 25, 2009 [Page 27]

Internet-Draft SCEP January 2009
time, the requester has received its own certificate.

5.4.

4.5. CRL Access

The CRL query message defined in this section 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 degenerated PKCS#7
[RFC2315] 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 certificate certification authority certificate has been
downloaded to the end entity.

PostCondition: CRL sent back to the requester.

5.4.1. GetCRL Message format

The

4.5.1. CRL is identified by using both CA's issuer name and the CA
certificate's serial number, combined into an ASN.1
issuerAndSerialNumber type, as defined in PKCS#7 Section 6.7. This
constitutes the content of the pkiMessage with messageType GetCRL.

In addition to the authenticatedAttributes required for a valid
PKCS#7, the pkiMessage MUST include the following:

o messageType set to GetCRL

o transactionID

o senderNonce

5.4.2. CertRep Access Response Message Format

The CRL is sent back to the requester through CertRep message. The
information portion of this message is a degenerated PKCS#7 [RFC2315]
SignedData degenerate certificates-only
Signed-data (Section 3.3) which contains only CRL attached to the raw DER encoded CRL.

Nourse, et al. Expires July 25, 2009 [Page 28]

Internet-Draft SCEP January 2009

5.5.
crls field of the Signed-Data.

4.6. Get Certificate Next Certification Authority Certificate

To get

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 certificate, (or RA) signing key.

Clients MUST validate the requester does a "HTTP GET" with a URL
that identifies a CGI script signature on the server and an optional CA issuer
identifier as the parameter to the CGI script. SignedData PKCS#7
[RFC2315] before accepting any of its contents.

The response content of the SignedData PKCS#7 [RFC2315] is either a single X.509 CA certificate ("CA mode"), or a PKCS7 degenerate
certificates-only Signed-data (Section 3.3) message containing the
new CA certificate and any new RA certificates
("RA mode"). The client can determine which mode the CA operates certificates, as defined in
by which response it gets.

Once
Section 5.2.1.1.2, to be used when the current CA certificate is received by
expires.

If the requester, a fingerprint
is generated using CA (or RA) does not have the SHA1, SHA256, SHA512 or MD5 hash algorithm on Rollover certificate(s) it MUST
reject the whole CA certificate. If request. It SHOULD also remove the requester GetNextCaCert setting

Nourse & Vilhuber Expires October 3, 2009 [Page 30]

Internet-Draft SCEP April 2009

from the capabilities until it does not have a
certificate path to a trusted CA certificate, rollover certificates.

If there are any RA certificates in this fingerprint may be
used to verify the certificate, response, clients MUST check
that these RA certificates are signed by some positive out-of-band means,
such 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 a phone call.

5.5.1. GetCACert 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=GetCACert" "?operation=" OPERATION "&message=" CA-IDENT MESSAGE

General GET Syntax

where:

o CGI-PATH defines the actual CGI path to invoke the CGI program
which
that parses the request.

o CGI-PROG is set to be the string "pkiclient.exe" and this "pkiclient.exe". This is
expected
intended to be the program that the CA will use to handle the SCEP
transactions.
transactions, though the CA may ignore CGI-PROG and use only the
CGI-PATH.

o CA-IDENT OPERATION depends on the SCEP transaction and is any string which defined in the
following sections.

o MESSAGE depends on the SCEP transaction and is understood by defined in the CA.
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
example, 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 could MAY be a domain name like ietf.org. If a
certificate string that represents the
certification authority issuer identifier, if such has multiple been set by
the CA certificates this field can
be used to distinguish which is required. Otherwise it may be
ignored.

5.5.2. 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.5.2.1. CA Certificate Only Response

A binary X.509 CA certificate is sent back as a MIME object with a
Content-Type of application/x-x509-ca-cert.

Nourse, et al. Expires July 25, 2009 [Page 29]

Internet-Draft SCEP January 2009

5.5.2.2. CA and RA Certificates Response

When an RA exists, both CA and RA certificates must be sent back in
the response to the GetCACert request. The RA certificate(s) must be
signed by the CA. A certificates-only PKCS#7 [RFC2315] SignedData is
used to carry the certificates to the requester, with a Content-Type
of application/x-x509-ca-ra-cert.

5.5.3. Get Next Certificate Authority Certificate

5.5.3.1. GetNextCACert HTTP Message Format

"GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-
IDENT

The response to this message is a PKCS#7 [RFC2315] certificates-only
message containing where a CA certificate (and possibly RA certificates) to
be used when exists and the current CA certificate expires, signed requester communicates with the
current CA certificate (or RA certificate, if
during the enrollment.

5.2.1.1.1. CA is in RA mode.
Note that Certificate Only Response

The response will have a PKCS#7 [RFC2315] is returned even 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 mode.

5.5.3.2. GetCACaps HTTP Message Format

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

This message requests capabilities from CA. Certificate Response

5.2.1.1.2. CA and RA Certificates Response

The response is will have a list Content-Type of text capabilities, "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 Appendix F. Support for 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 optional, but if it is not supported, the client should
assume that none an example of the capabilities in Appendix F are supported.

5.6. Get Certificate Authority Certificate Chain

GetCACertChain provides
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 way 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 get the entire certificate chain.

5.6.1. GetCACertChain HTTP Message Format

"GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-
IDENT

where:

CGI-SCRIPT and CA-IDENT are as described for GetCACert.

5.6.2. "PKIOperation".

MESSAGE consists of a base64-encoded DER-encoded GetCert SCEP
message.

5.2.4.1. GetCert Response

The body of this response for GetCACertChain is consists of a certificates-only PKCS#7
[RFC2315] SignedData to carry the certificates DER-encoded CertRep SCEP
message defined in Section 4.4.1.

5.2.5. GetCRL

OPERATION MUST be set to the requester, with
a Content-Type "PKIOperation".

MESSAGE consists of application/x-x509-ca-ra-cert-chain.

Nourse, et al. a base64-encoded DER-encoded GetCRL SCEP message.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 30] 33]

Internet-Draft SCEP January April 2009

5.6.3. Backwards Compatibility

Versions

5.2.5.1. GetCRL Response

The body of this response consists of a DER-encoded CertRep SCEP prior to revision 3 do not support GetCACertChain or
GetNextCACert. Certificate Authorities written to these prior
versions will not
message defined in Section 4.5.1.

5.2.6. GetNextCaCert

OPERATION MUST be able set to process the message and may return an
HTML error.

To avoid this, clients should send the GetCACert message first. If
the returned certificate is self-signed "GetNextCaCert".

MESSAGE MAY be ommitted, or is signed by it MAY be a Certificate
Authority string that is trusted by represents the client, then it is not necessary to
send
certification authority issuer identifier, if such has been set by
the GetCACertChain message and it should not be sent.

An old CA in Administrator.

5.2.6.1. GetNextCACert Response

The response will have a two-deep hierarchy might still get Content-Type of "application/
x-x509-next-ca-cert".

The body of this message from response consists of a
client if the client did not trust either that CA or its issuer. 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. Acknowledgements 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, VeriSign, Inc) and Alex Deacon of Verisign, 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 keypair 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 keypair
indiscriminately key pair
to encrypt and sign PKCS#7 [RFC2315] transport messages. messages, regardless
of the key usage of the CA certificate. This is generally considered
undesirable, as this weakens the CA keypair

Nourse, et al. Expires July 25, 2009 [Page 31]

Internet-Draft SCEP January 2009

over time (it is generally accepted that using any key weakens it
over time, as it gives widens the possibility of an attacker implementation
weakness, and provides

o another place that the private key must be used (and hence is
slightly more data vulnerable to work with). 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 keypair 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
keypair. 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 challengePassword sent in the PKCS#10 enrollment request is
signed (via inclusion in a pkiMessage) and encrypted (via inclusion by way of being encapsulated in a pkcsPKIEnvelope). 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 challengePassword is used to automatically authenticate an
enrollment request, it is recommend 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 will not 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.

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

Nourse, et al. Expires July 25, 2009 [Page 32]

Internet-Draft SCEP January 2009
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.

[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S.,

[RFC2985] Nystrom, M. and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2560, June 1999. 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.

[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates",
RFC 4523, June 2006.

[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS

Nourse, et al. Expires July 25, 2009 [Page 33]

Internet-Draft SCEP January 2009

(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. Cisco Requester Subject Name Definition

The ip address and the FQDN of a SCEP client should be included in
the V3 extension subjectAltName. When the subjectAltName extension
attribute is present, both the subjectAltName fields and the
subjectName field could have the IP address and the FQDN information.

When the X.500 directory is used by the CA to define the name space,
the subject name defined above become a RDN which is part of DN bound
to the requester's public key in the certificate. A sample of DN
assigned by Entrust CA is given below (assume the same
ciscoRouterAlice is used as the requester defined subject name):
OU = InteropTesting, O = Entrust Technologies, C = CA
RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} "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.

Appendix B. 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, et al.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 34] 38]

Internet-Draft SCEP January 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, et al.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 35] 39]

Internet-Draft SCEP January April 2009

Certificate Enrollment Request

Appendix C. 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 D. CRL Query by means of LDAP

In order to retrieve the CRL by means of LDAP, the client needs to
know where in the directory it is stored. The certificate must
contain a CRL Distribution Point extension encoded as a DN or as an
LDAP URI.

For example, the certificate issued by Entrust VPN contains the
following DN as the CRL distribution point:
CN = CRL1, O = cisco, C = US

The ASN.1 encoding of this distribution point is:
30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06
03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03
13 04 43 52 4C 31

The ldap form would be:
ldap://servername/CN=CRL1,O=cisco,C=US

Nourse, et al. Expires July 25, 2009 [Page 36]

Internet-Draft SCEP January 2009

Appendix E. 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. An identity is defined
by the combination of FQDN, the IP address and the client serial
number. FQDN is the required name attribute. It is important to
notice that, a client named as Alice.cisco.com is different from ensure the
client named as Alice.cisco.com plus IPAddress 192.0.2.4. 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 XXX).
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
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
identify a transaction in its database. At the CA

Nourse, et al. requester side, it

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 37] 40]

Internet-Draft SCEP January April 2009

enforces the certificate-name uniqueness property defined in
Section 2.1.1.1.

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

"Client Sends PKCSReq message with

generates a transaction ID 1 to identifier which is included in PKCSReq. If
the CA. The CA signs the certificate and constructs returns a CertRep Message containing response of PENDING, the signed certificate 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 ID 1. with the same
key pair. The client receives second enrollment will have the message and installs transaction
identifier. At the server side, instead of accepting the certificate locally."

Successful Enrollment Case: no manual authentication
PKCSReq (1) ----------> CA Signs Cert
Client Installs Cert <---------- CertRep (1) SIGNED CERT

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
Client Installs Cert <---------- CertRep (10) SIGNED CERT

Resync Case - CA Receive and Signs PKCSReq, Client Did not receive
CertRep: PKCSReq (3) ----------> Cert Request goes into queue
<---------- CertRep (3) PENDING
GetCertInitial (3) ---------->
<---------- CertRep (3) PENDING as
a new enrollment request, it should respond as if another
GetCertInitial (3) ----------->
<----------- CA signed Cert and message had been sent back
CertRep(3)
(Time Out) with that transaction ID. In
another word, the second PKCSReq (3) ----------> Cert already signed, sent back should be taken as a
resynchronization message to
client
Client Installs Cert <---------- CertRep (3) SIGNED CERT

Case when NVRAM allow the enrollment resume as the same
transaction.

It is lost important to keep the transaction id unique since SCEP requires
the same policy and client has same identity be applied to generate a new key pair,
there is no change of the same subject name information:

Nourse, et al. Expires July 25, 2009 [Page 38]

Internet-Draft
and key pair binding. In the current implementation, an SCEP January 2009

PKCSReq (4) ----------> CA Signs Cert
Client Installs Cert <---------- CertRep (4) SIGNED CERT
(Client looses Cert)
PKCSReq (5) ----------> There is already client
can only assume one identity. At any time, only one key pair, with a valid cert
given key usage, can be associated with
this DN.
Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR
PKCSReq (5) ----------> the same identity.

The following gives several examples of client to CA Signs Cert transactions.

Client Installs Cert <---------- CertRep (5) SIGNED CERT
Case when client admin resync actions are indicated in the enrollment using a different PKCS#10:
PKCSReq (6) ----------> left column, CA Signs Cert
<---------- CertRep (6) SIGNED CERT

(Client timeout and admin starts another enrollment with a different
PKCS#10, but actions are
indicated in the same transaction id) 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 (6) message with different PKCS#10
----------> There is already transaction ID 1 to the CA. The
CA signs the certificate and constructs a valid cert with
this entity (by checking FQDN).
<---------- CertRep (6) INVALID PKCS#10 CERT
ERROR

Client admin either revokes Message containing
the existing signed certificate or corrects the
error by enrolling with a transaction ID 1. The client receives
the same PKCS#10 as message and installs the first PKCSReq(6) certificate locally."

Successful Enrollment Case: no manual authentication
PKCSReq (6) (1) ----------> CA find the existing Signs Cert
Client Installs Cert <---------- CertRep (6) (1) SIGNED CERT
Resync case when server is slow in response:

Simple Enrollment Example

Nourse & Vilhuber Expires October 3, 2009 [Page 41]

Internet-Draft SCEP April 2009

Successful Enrollment Case: manual authentication required
PKCSReq (13) (10) ----------> Cert Request goes into Queue
Client Polls <---------- CertRep (13) (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (13) (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (13) (10) PENDING
GetCertInitial (10) ----------> Still pending
Client Polls <---------- CertRep (13) (10) PENDING
GetCertInitial (10) ----------> Still pending
(TimeOut) 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 (13) (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 (13) (4) ----------> Still pending
Client polls CA Signs Cert
<---------- CertRep (13) PENDING
GetCertInitial ----------> Crete has been signed (4) SIGNED CERT
Client Installs Crete Cert
(Client looses Cert)
PKCSReq (5) ----------> There is already a valid cert with
this DN.
<---------- CertRep (13) SIGNED CERT
* Case 2 (5) BAD REQUEST
Admin Revokes
PKCSReq (13) (5) ----------> Cert has been signed
Client Installs CA Signs Cert
<---------- CertRep (13) (5) SIGNED CERT

Nourse, et al. Expires July 25, 2009 [Page 39]

Internet-Draft SCEP January 2009
Client Installs Cert

Retrieving lost certificate

Appendix F. 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):

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 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, no data is
returned. a server
SHOULD return an empty message. A server MAY simple return an HTTP
error.

The appropriate HTML headers are returned in any case. 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 POSTPKIOperation
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.

Nourse, et al. Expires July 25, 2009 [Page 40]

Internet-Draft SCEP January 2009

Appendix G. 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 ---------->
<---------- CertRep (3) New CA certificate

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

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

GetNextCaCert Transaction

Appendix H. F. PKIOperation via HTTP POST Message

If the remote CA supports it, any of the PKCS#7-encoded 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, GetCACertChain, 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>

General POST Syntax

The client can verify that the CA supports SCEP messages via POST by
looking for the "POSTPKIOperation" capability (See Appendix F).

Nourse, et al. Expires July 25, 2009 [Page 41]

Internet-Draft SCEP January 2009 D).

Authors' Addresses

Andrew Nourse
Cisco Systems, Inc.
510 McCarthy Drive
Milpitas, CA
USA

Email: nourse@cisco.com

Xiaoyi Liu
Cisco Systems, Inc. Inc
510 McCarthy Drive
Milpitas, CA
USA

Phone:
Fax:
Email: xliu@cisco.com
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

Cheryl Madson
Cisco Systems, Inc.
510 McCarthy Drive
Milpitas, CA
USA

Email: cmadson@cisco.com

Nourse, et al.

Nourse & Vilhuber Expires July 25, October 3, 2009 [Page 42] 46]

----