This patch adds support for signing requests with an existing key.
It was taken from CertNanny <http://www.cynops.de/oss/CertNanny/>
diff -uN sscep/Makefile sscep-ng2/Makefile
--- sscep/Makefile 2003-01-22 06:23:18.000000000 +0100
+++ sscep-ng2/Makefile 2006-04-25 19:38:49.000000000 +0200
@@ -7,13 +7,14 @@
CC = gcc
CFLAGS = -Wall -O
+LDLIBS = -lcrypto
MAN = sscep.8
PROG = sscep
OBJS = sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o
$(PROG): $(OBJS)
- $(CC) $(CFLAGS) -lcrypto -o $(PROG) $(OBJS)
+ $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o $(PROG) $(OBJS) $(LDLIBS)
clean:
rm -f $(PROG) $(OBJS) $(MAN) core
diff -uN sscep/README sscep-ng2/README
--- sscep/README 2003-04-17 07:49:46.000000000 +0200
+++ sscep-ng2/README 2006-04-28 10:27:44.000000000 +0200
@@ -51,11 +51,13 @@
o iPlanet CMS (getca and enroll works)*
o VeriSign Onsite (getca and enroll works)**
o Entrust VPN Connect (getca and enroll works)***
+o OpenCA (getca, enroll, getcrl and automatic approval works)****
(*) by default, subjectAltName extensions are dropped from certificate
(**) only DNS subjectAltName allowed (demo mode)
(***) demo requires to use /C=US/O=Entrust
-
+(****) automatic approval according to newer SCEP drafts requires
+ OpenCA 0.9.2.4 or higher
HOW TO COMPILE
==============
@@ -76,7 +78,7 @@
$ ./sscep
-sscep version 20030131
+sscep version 2005XXXX
Usage: ./sscep OPERATION [OPTIONS]
@@ -103,6 +105,8 @@
OPTIONS for OPERATION enroll are
-k <file> Private key file
-r <file> Certificate request file
+ -K <file> Signature private key file
+ -O <file> Signature certificate (used instead of self-signed)
-l <file> Write enrolled certificate in file
-e <file> Use different CA cert for encryption
-L <file> Write selfsigned certificate in file
@@ -152,6 +156,16 @@
CAIdentifier Some CAs require you to define this. Example: mydomain.com
Command line option: -i
+CheckSubjectName
+ Check subject DN in the certificate return by the CA. The
+ default is to match on the public key only. Up to version
+ 20040325 sscep checked on the subject DN only, which is a
+ problem e.g. if the CA adds a SER attribute, enforces a
+ naming policy or fixes encoding errors (e.g. with Java keytool
+ and DC).
+ Example: yes
+ Command line option: -C
+
CertReqFile Certificate request file created with mkrequest.
Example: ./local.csr
Command line option: -r
@@ -171,6 +185,21 @@
the signature. Example: ./enc.crt
Command line option: -e
+SignCertFile Instead of creating a self-signed certificate from the
+ new key pair use an already existing certficate/key to
+ sign the SCEP request. If the "old" certificate and
+ key is used, the CA can verify that the holder of the
+ private key for an existing certificate re-enrolls for
+ a renewal certificate, allowing for automatic approval
+ of the request. Requires specification of the corresponding
+ signature private key file (-K, SignKeyFile).
+ Example: ./sig.crt
+ Command line option: -O
+
+SignKeyFile See SignCertFile. Specifies the corresponding private key.
+ Example: ./sig.key
+ Command line option: -K
+
FingerPrint Display fingerprint algorithm. Available algorithms are md5
and sha1. Default is md5.
Command line option: -F
@@ -367,6 +396,23 @@
the challenge password), it returns SUCCESS as a first reply. Otherwise, the
enrollment requires manual signing and authentication (perhaps a phone call).
+Newer SCEP draft versions allow to use the existing certificate (issued
+by the CA) to authenticate a renewal request. In this context, the SCEP
+request with the new public key is signed with the old certificate and
+key (instead of using a self-signed certificate created from the new
+key pair).
+To use this feature, use the command line options -O and -K to specify
+the old certificate and private key (SignCertFile and SignCertKey
+in the configuration file).
+The actual behaviour of the SCEP server depends on the CA policy and
+on the capabilities of the SCEP server (not all servers implement
+this feature, using the existing certificate with an older SCEP server
+may or may not work, depending on implementation).
+
+Note: Newer versions of OpenCA (http://www.openca.info/) support
+an SCEP server that is capable of automatically approving SCEP requests
+signed with the already existing key pair.
+
STEP 5 - Use certificate
========================
diff -uN sscep/cmd.h sscep-ng2/cmd.h
--- sscep/cmd.h 2003-01-30 08:57:34.000000000 +0100
+++ sscep-ng2/cmd.h 2006-04-28 10:01:10.000000000 +0200
@@ -16,6 +16,9 @@
int c_flag;
char *c_char;
+/* Check subject DN */
+int C_flag;
+
/* Debug? */
int d_flag;
@@ -51,10 +54,18 @@
char *k_char;
int k_flag;
+/* Private key of already existing certificate */
+char *K_char;
+int K_flag;
+
/* Request count */
int n_flag;
int n_num;
+/* Already existing certificate (to be renewed) */
+char *O_char;
+int O_flag;
+
/* Proxy */
char *p_char;
int p_flag;
diff -uN sscep/draft-nourse-scep-11.txt sscep-ng2/draft-nourse-scep-11.txt
--- sscep/draft-nourse-scep-11.txt 1970-01-01 01:00:00.000000000 +0100
+++ sscep-ng2/draft-nourse-scep-11.txt 2006-04-25 16:27:03.000000000 +0200
@@ -0,0 +1,2367 @@
+
+INTERNET DRAFT Xiaoyi Liu
+draft-nourse-scep-11.txt Cheryl Madson
+expires 11 Aug 2005 David McGrew
+(revised 11 Feb 2005) Andrew Nourse
+ Cisco Systems
+
+Category: Informational 11 Feb 2005
+
+
+Cisco Systems' Simple Certificate Enrollment Protocol(SCEP):
+
+Status of this Memo
+
+This document is an Internet-Draft and is NOT offered in accordance
+with Section 10 of RFC2026, and the author does not provide the IETF
+with any rights other than to publish as an Internet-Draft
+
+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 memo provides information for the Internet community. This memo
+does not specify an Internet standard of any kind. Distribution of
+this memo is unlimited.
+
+By submitting this Internet-Draft, I certify that any applicable patent
+or other IPR claims of which I am aware have been disclosed, or will be
+disclosed, and any of which I become aware will be disclosed, in accordance
+with RFC 3668.
+
+Abstract
+
+This document specifies the Simple Certificate Enrollment Protocol,
+a PKI communication protocol which leverages existing technology by
+using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment
+protocol developed by Verisign, Inc. for Cisco Systems, Inc.
+It now enjoys wide support in both client and CA implementations.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3
+ 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7
+ 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10
+ 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13
+ 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14
+ 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14
+
+ Liu/Madson/McGrew/Nourse [Page 2]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15
+ 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16
+ 5.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . 16
+ 5.2 Poll for Requester Initial Certificate . . . . . . . . . . 22
+ 5.3 Certificate Access . . . . . . . . . . . . . . . . . . . . 26
+ 5.4 CRL Access . . . . . . . . . . . . . . . . . . . . . . . 27
+ 5.5 Get Certificate Authority Certificate . . . . . . . . . . 31
+ 5.6 Get Certificate Authority Certificate Chain . . . . . . . 33
+ 6. Security Considerations . . . . . . . . . . . . . . . . . 33
+ 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33
+ Appendix A. Cisco Requester Subject Name Definition . . . . . . 34
+ Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35
+ Appendix C. Private OID Definitions . . . . . . . . . . . . . 36
+ Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36
+ Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37
+ Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40
+ Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41
+ Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42
+ Appendix Y. Author Contact Information. . . . . . . . . . . . . 43
+ Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43
+
+Section 1. Introduction
+
+Public key technology is becoming more widely deployed and is becoming
+the basis for standards based security, such as the Internet Engineering
+Task Force's IPSEC and IKE protocols. With the use of public key
+certificates in network security protocols comes the need for a
+certificate management protocol that Public Key Infrastructure (PKI)
+clients and Certificate Authority servers can use to support certificate
+life cycle operations such as certificate enrollment and revocation, and
+certificate and CRL access.
+
+In the following, Section 2 gives an overview of the PKI operations,
+and Section 2.4 describes the security goals of the protocol and the
+mechanisms used to achieve them. The transport protocol and the
+security protocol PKCS#7 are described at Section 3 and Section 4,
+respectively. The last section, Section 5, specifies each PKI
+operation in terms of the message formats and the data structures of
+each operation.
+
+The appendices provide detailed specifications and examples. Requester
+subject names are specified in Appendix A, attribute OIDs are
+specified in Appendix C , and the SCEP state transitions are described
+in Appendix E. An example of a certificate enrollment request is
+provided in Appendix B, and an example LDAP query URL encoding is
+provided in Appendix D.
+
+The authors would like to thank Peter William of ValiCert, Inc.
+(formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and
+Christopher Welles of IRE, Inc. for their contributions to this protocol
+and to this document.
+
+ Liu/Madson/McGrew/Nourse [Page 3]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+2.0 The Goal of SCEP
+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:
+
+ CA and RA public key distribution
+ Certificate enrollment
+ Certificate revocation
+ Certificate query
+ CRL query
+
+Certificate and CRL access can be achieved by using 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 RFC2459, will be specified in a future version of
+this document. In Section 2.1, we first define PKI entity types as well
+as the properties of each entity type. In Section 2.2, the PKI
+operations are described at functional level. Section 2.3 describes the
+transaction behavior of each PKI operations. The complete PKI messages
+are covered in Section 5.
+
+2.1 SCEP Entity types
+
+The entity types defined in SCEP are the "requester" type (i.e., IPSEC
+clients), the Certificate Authority (CA) entity type, and the
+Registration Authority entity type (RA). A requester is sometimes
+called a "SCEP client" in the following.
+
+2.1.1 Requesters
+
+A requester is an entity whose name is defined in a certificate
+subject name field and optionally, in SubjectAltName, a X.509
+certificate V3 extension. As a requester, a SCEP client is identified
+by a subject name consisting of the following naming attributes:
+
+ Fully qualified domain name, for example, router.cisco.com
+ IP address, Serial number, and/or x.500 distinguished name
+
+The fully qualified domain name is required for a requester that intends
+to use the certificate for ISAKMP. The IP address, serial number, and
+x.500 distinguished name are optional name attributes. In the
+certificate enrollment request, the PKCS#10 subject field contains the
+required and optional name attributes. The distinguished name, if any,
+should be the subject name field, while any domain name, serial number,
+or IP address supplied should be in the subjectAltName field. The
+subject name field may be empty (if there is no distinguished name)
+or the subjectAltName may be omitted, but not both.
+
+It is important to note that a client named as Alice.cisco.com is
+different than a client named as Alice.cisco.com plus the IP address
+name attribute 117.96.1.219. From CA point of view, the Distinguished
+names assigned in these two cases are distinct names.
+
+
+ Liu/Madson/McGrew/Nourse [Page 4]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP
+address and User FQDN) must be presented in certificate's SubjectAltName
+extension. Multiple IPSEC entity names, (if any) are encoded as multiple
+values of a single SubjectAltName extension. The CA has the authority
+to assign a distinguished name to a requester, whether or not one was
+included in the request. The assigned DN should contain the SCEP client
+names as the relative DN.
+
+The attribute identifiers and an example of SCEP client subject name are
+specified in Appendix A. Appendix B has an example from Cisco VPN Client
+enrollment request.
+
+2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness
+
+A requester is required to generate asymmetric key pairs and to provide
+storage to store its private keys. 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. The public key pairs can be generated with a specific
+key usage. The key usage is conveyed to the CA through the certificate
+enrollment request. All current SCEP client implementations expect that
+there will be only one pair of keys for a given subject name
+and key usage combination and CA, at any 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 key pairs with a given key usage. At any time, if
+the subject name is changed, or if the key is updated, the existing
+certificate would have to be revoked before a new one could be issued.
+
+It is desirable that the CA enforce certificate-name uniqueness, but
+it is not mandatory. However 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 can the second request merely be rejected.
+If a client times out from polling for a pending request it can
+resynchronize by reissuing the original request with the original
+subject name, key, and transaction ID. This should return the status of
+the original transaction, including the certificate if it was granted.
+It should not create a new transaction unless the original cert has been
+revoked, or the transaction arrives more than halfway through the
+validity time of the original certificate.
+
+An enrollment request that occurs more than halfway through the validity
+time of an existing certificate for the same subject name and key usage
+MAY be interpreted as a re-enrollment or renewal request and 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
+2.1.1.3. See also appendix G.
+
+2.1.1.2 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
+ Liu/Madson/McGrew/Nourse [Page 5]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+cryptographically secure manner. This requirement is needed to
+prevent a "man in the middle" attack, in which an adversary that can
+manipulate the data as it travels between the protocol participants
+can subvert the security of the protocol. To satisfy this
+requirement, SCEP provides two authentication methods: manual
+authentication, and authentication based on pre-shared secret. 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 or MD5
+`fingerprint' generated on the PKCS#10 (before PKCS #7 enveloping and
+signing) must be compared out-of-band between the server 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. When utilizing a
+pre-shared secret scheme, the server should distribute a shared secret
+to the requester which can uniquely associate the enrollment request
+with the given end entity. 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. When creating the enrollment
+request, the requester is asked to provide a challenge password. When
+using the pre-shared secret scheme, the requester must enter the
+re-distributed secret as the password. In the manual authentication
+case, the challenge password only used to authenticate a request for
+the certificate's revokation. This challenge password is included as
+a PKCS#10 attribute, and is sent to the server as encrypted data. The
+PKCS#7 envelope protects the privacy of the challenge password with
+DES encryption.
+
+2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates
+
+In this protocol, the communication between the requester and the
+certificate authority is secured by using PKCS#7 as the messaging
+protocol. PKCS#7, however, is a protocol 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. If the requesting
+system already has a certificate issued by the CA, that certificate
+may 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. If the requester has no certificate issued
+by the CA, or if the CA does not support and permit renewal, the
+requestor must generate a self-signed certificate with the requester
+subject name (the same name later used in the PKCS#10) as both issuer
+and subject name. During the certificate enrollment, the requester
+will first post itself as the signing authority by attaching the
+self-signed certificate to the signed certificate request. When the
+Certificate Authority makes the envelope on the issued certificate
+using the public key included in the self-signed certificate, it
+should use the same issuer name and serial number as conveyed in the
+self-signed certificate to inform the end entity on which private key
+should be used to open the envelope.
+ Liu/Madson/McGrew/Nourse [Page 6]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Note that when a client enrolls for separate encryption and signature
+certificates, it may use the signature certificate to sign both
+requests, and then expect its signature key to be used to encrypt
+both responses. In any case, the recipientinfo on the envelope should
+reflect the key used to encrypt the request.
+
+2.1.1.4 Trusted CA Store
+
+To support interoperability between IPSEC peers whose certificates are
+issued by different CA, SCEP allows the users to configure multiple
+trusted certificates. Trusted certificates are have been configured as
+such in the client, based on some out-of-band means such as a "fingerprint".
+These trusted certificates are used to verify certificate chains that end
+in those certificates.
+
+2.1.2 Certificate Authority
+
+A Certificate Authority(CA) is an entity whose name is defined in the
+certificate issuer name field. Before any PKI operations can begin,
+the CA generates its own public key pair and creates a self-signed CA
+certificate, or causes another CA to issue a certificate to it.
+Associated with the CA certificate is a fingerprint which will be used
+by the requester to authenticate the received CA certificate if it is
+self-signed. The fingerprint is created by calculating a SHA-1 or MD5
+hash on the whole CA certificate. Before any requester can start its
+enrollment, this CA certificate has to be configured at the entity
+side securely. For IPSEC clients, the client certificates must have
+SubjectAltName extension. To utilize LDAP as a CRL query protocol,
+the certificates must have a CRL Distribution Point. Key usage is
+optional. Without key usage, the public key is assumed as a general
+purpose public key and it can be used for all the purposes.
+
+A Certificate Authority may enforce certain name policy. When using
+X.500 directory name as the subject name, all the name attributes
+specified in the PKCS#10 request should be included as Relative DN. All
+the name attributes as defined in RFC2459 should be specified in the
+SubjectAltName. An example is provided in Appendix A.
+
+ If there is no LDAP query protocol support, the Certificate Authority
+should answer certificate and CRL queries, and to this end it should be
+online all the time.
+
+The updating of the CA's public key is addressed in Appendix G.
+
+2.1.3 Registration Authorities
+
+In an environment where an RA is present, a requester performs
+enrollment through the RA. In order to setup a secure channel with an RA
+using PKCS#7, 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 the
+context of PKI operation definitions.
+ Liu/Madson/McGrew/Nourse [Page 7]
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+2.2 SCEP Operations Overview
+
+In this section, we give a high level overview of the PKI operations as
+defined in SCEP.
+
+2.2.1 Requester Initialization
+
+The requester initialization includes the key pair generation and the
+configuring of the required information to communicate with the
+certificate authority.
+
+2.2.1.1 Key Pairs
+
+Before a requester can start PKI transaction, it must have at least one
+asymmetric key pair, using the selected algorithm (the RSA algorithm is
+required in SCEP, and is the only algorithm in current implementations).
+
+Key pairs may be intended for particular purposes, such as encryption only,
+or signing only. The usage of any associated certificate can be restricted
+by adding key usage and extended key usage attributes to the PKCS#10.
+
+2.2.1.2 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, and
+ the HTTP proxy information in case there is no direct Internet
+ connection to the server,
+3. If CRLs are being published by the CA to an LDAP directory server,
+ and there is a CRL Distribution Point containing only an X.500 directory
+ name, then the client will need to know the LDAP server fully-qualified
+ domain name or IP address. CRL Distribution Points are discussed in
+ more detail in RFC 2459.
+
+
+2.2.2 CA/RA Certificate Distribution
+
+Before any PKI operation can be started, the requester needs to get
+the CA/RA certificates. At this time, since no public key has been
+
+ Liu/Madson/McGrew/Nourse [Page 8]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+exchanged between the requester and the CA/RA, the message to get the
+CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the
+CA/RA certificate distribution is implemented as a clear HTTP Get
+operation. After the requester gets the CA certificate, it has to
+authenticate the CA certificate by comparing the finger print with the
+CA/RA operator. Since the RA certificates 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 Cert: HTTP Get message
+ ----------------------------->
+ CA/RA Cert download: HTTP Response message
+ <---------------------------------------
+ Compute finger print and
+ call CA operator.
+ Receive call and check finger print
+
+If an RA is in use, a degenerated PKCS#7 with a certificate chain
+consisting of both RA and CA certificates is sent back to the end
+entity. Otherwise the CA certificate is directly sent back as the
+HTTP response payload.
+
+
+2.2.3 Certificate Enrollment
+
+A requester starts an enrollment transaction by creating a certificate
+request using PKCS#10 and sends it to the CA/RA enveloped using the
+PKCS#7. After the CA/RA receives the request, it will either
+automatically approve the request and send the certificate back, or it
+will require the requester to wait until the operator can manually
+authenticate the identity of the requester. Two attributes are
+included in the PKCS#10 certificate request - a Challenge Password
+attribute and an optional ExtensionReq attribute which will be a
+sequence of extensions the requester would like to be included in its
+V3 certificate extensions. The Challenge Password may be used to
+authenticate either the enrollment request itself, or a verbal
+revocation request for the issued certificate in the event of key
+compromise or other reason.
+
+In the automatic mode, the transaction consists of one PKCSReq PKI
+Message, and one CertRep PKI message. In the manual mode, the requester
+enters into polling mode by periodically sending a GetCertInitial PKI
+message to the server, until the server operator completes the manual
+authentication, after which the CA will respond to GetCertInitial by
+returning the issued certificate. A CA MAY run in automatic mode for
+preapproved requests, and manual mode for the rest. A request with a
+non-null password is not necessarily a pre-approved request. It is up
+to the CA server to decide. Polling mode is entered whenever the
+server returns a PENDING response.
+
+ Liu/Madson/McGrew/Nourse [Page 9]
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+The transaction in automatic mode:
+
+ REQUESTER CA SERVER
+
+PKCSReq: PKI cert. enrollment msg
+ --------------------------------> CertRep: pkiStatus = SUCCESS
+ certificate attached
+ <------------------------------
+ Receive issued certificate.
+
+The transaction in manual mode:
+
+ REQUESTER CA SERVER
+ PKCSReq: PKI cert. enrollment msg
+ --------------------------------> CertRep: pkiStatus = PENDING
+ <------------------------------
+ GetCertInitial: polling msg
+ --------------------------------> CertRep: pkiStatus = PENDING
+ <------------------------------
+ ................. <manual identity authentication................
+
+ GetCertInitial: polling msg
+ --------------------------------> CertRep: pkiStatus = SUCCESS
+ certificate attached
+ <------------------------------
+ Receive issued certificate.
+
+2.2.4 Requester Certificate Revocation
+
+A requester should be able to revoke its own certificate. Currently
+the revocation is implemented as a manual process. In order to revoke a
+certificate, the requester makes a phone call to the CA server
+operator. The operator will come back asking the ChallengePassword
+(which has been sent to the server as an attribute of the PKCS#10
+certificate request). If the ChallengePassword matches, the certificate
+is revoked. The reason of the revocation is documented by CA/RA.
+
+2.2.5 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 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 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
+
+ Liu/Madson/McGrew/Nourse [Page 10]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+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 message and one CertRep PKI message:
+
+ REQUESTER CA SERVER
+ GetCert: PKI cert query msg
+ -------------------------------> CertRep: pkiStatus = SUCCESS
+ certificate
+attached
+ <-----------------------------
+ Receive the certificate.
+
+2.2.6 CRL Distribution
+
+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 three methods to query CRL.
+
+The CRL may be retrieved by a simple HTTP GET. If the CA supports this
+method, it should encode the URL into a CRL Distribution Point extension
+in the certificates it issues. Support for this method should be
+incorporated in new and updated clients, but may not be in older
+versions.
+
+The second method is to query CRL using LDAP. This assumes the CA server
+supports CRL LDAP publishing and issues the CRL Distribution Point in
+the certificate. The CRL Distribution Point is encoded as a DN. Please
+refer to Appendix D for the examples of CRL Distribution Point.
+
+The third method is implemented for the CA which does not support LDAP
+CRL publishing or does not implement the CRL Distribution Point. In this
+case, a CRL query is composed by creating a message consists of the CA
+issuer name and the CA's certificate serial number. This method is
+deprecated because it does not scale well and requires the CA to be a
+high-availability service.
+
+The message is sent to the CA in the same way as the other SCEP
+requests: The transaction to query CRL consists of one GetCRL PKI
+message and one CertRep PKI message which have no certificates but CRL.
+
+ REQUESTER CA SERVER
+ GetCRL: PKI CRL query msg
+ ----------------------------------> CertRep: CRL attached
+ <--------------------------------
+
+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
+
+
+ Liu/Madson/McGrew/Nourse [Page 11]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+certificate 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 or MD5 hash on the public key value for which the
+enrollment request is made. This allows the SCEP client to reuse the
+same transaction identifier if it is reissuing a request for the same
+certificate (i.e. a certificate with the same subject, issuer, and key).
+The SCEP protocol requires that transaction identifiers be unique, so
+that queries can be matched up with transactions. For this reason, in
+those cases in which separate signing and encryption certificates are
+issued to the same requester, the keys must be different.
+
+2.3.2 State Transitions in Certificate Enrollment
+
+The requester state transitions during enrollment operation are
+indicated in the diagram below:
+ +-<------+
+ | |
+ GetCertInitial triggered by timeout or
+ | | manual authentication
+ | |
+ [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED]
+ | PKCSReq | CertRep with SUCCESS
+ | |
+ | |
+ +--------<-------------------+
+ request rejected, timeout, or error
+
+As described in 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 the
+state to CERT-ISSUED. In the case the server sending back the response
+with pending status, the requester will keep polling certificate
+response by sending GetCertInitial to the server, until either a CertRep
+with SUCCESS status is received, or the maximum polling number has been
+exceeded.
+
+If an error or timeout occurs in the CERT-REQ-PENDING state, the end
+entity will transition to the CERT-NONEXISTANT state.
+
+
+ Liu/Madson/McGrew/Nourse [Page 12]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+The client administrator will, eventually, start up another enrollment
+request. It is important to note that, as long as the requester does
+not change its subject name or keys, the same transaction id will be
+used in the "new" transaction. This is important because based on this
+transaction id, the certificate authority server can recognize this as
+an existing transaction instead of a new one.
+
+
+2.3.3 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
+upstanding request message. When using LDAP to query the 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 either SHA-1 or MD5, depending on the "SHA-1" CA Capability.
+[See Appendix F].
+
+The first and second goals are met through the use of PKCS#7 and PKCS#10
+encryption and digital signatures using authenticated public keys. The
+CA's public key is authenticated via the checking of the CA fingerprint,
+as specified in Section 2.1.2, and the SCEP client's public key is
+authenticated through the manual authentication or pre-shared secret
+authentication, as specified in Section 2.1.1.2. The third goal is met
+through the use of a Challenge Password for revocation, that is chosen
+by the SCEP client and communicated to the CA protected by the PKCS#7
+encryption, as specified in Section 2.2.4.
+
+The motivation of the first security goal is straightforward. The
+motivation for the second security goal is to protect the identity
+information in the enrollment requests and certificates. For example,
+two IPSEC hosts behind a firewall may need to exchange certificates, and
+may need to enroll certificates with a CA that is outside of a firewall.
+Most networks with firewalls seek to prevent IP addresses and DNS
+
+ Liu/Madson/McGrew/Nourse [Page 13]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+information from the trusted network leaving that network. The second
+goal enables the hosts in this example to enroll with a CA outside the
+firewall without revealing this information. The motivation for the
+third security goal is to protect the SCEP clients from denial of
+service attacks.
+
+Section 3 Transport Protocol
+
+In the SCEP protocol, HTTP is used as the transport protocol for the PKI
+messages.
+
+3.1 HTTP "GET" and "POST" Message Format
+
+The following is the syntax definition of a HTTP GET message sent from
+a requester to a certificate authority server:
+
+Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE
+where:
+ CGI-PATH defines the actual CGI path to invoke the CGI program which
+ parses the request.
+ CGI-PROG is set to be the string "pkiclient.exe". This is intended
+ to be the program that the CA will use to handle the SCEP transactions,
+ though the CA may ignore CGI-PROG and use only the CGI-PATH.
+ OPERATION is set to be the string "PKIOperation" when the GET message
+ carries a PKI message to request certificates or CRL; OPERATION is set
+ to be the string "GetCACaps", "GetCACert", "GetNextCACert" or
+ "GetCACertChain" when the GET operation is used to get CA capabilities,
+ CA/RA certificate, the replacement CA/RA certificates for when the
+ current ones expire, or the CA Cert chain (respectively).
+
+ When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI message,
+ When OPERATION is GetCACert, MESSAGE is a CRL distribution
+ point in URI format, otherwise, MESSAGE is a string which represents
+ the certificate authority issuer identifier.
+
+SCEP uses the HTTP "GET" and "POST" messages to request information from the CA.
+Requests for CA certificates or capabilities are sent in the clear, using "GET",
+with the OPERATION and MESSAGE fields identifying the requested data.
+CRLs may also be requested in the clear if the CA supports it.
+
+Other types of requests are sent using the PKCS#7 secure protocol.
+These may be issued by means of a GET operation with
+OPERATION and MESSAGE parameters in the Request-URL. OPERATION
+identifies the type of GET operation, and MESSAGE is actually the PKCS#7
+message Base64-Encoded.
+
+For example. a requester may submit a message via HTTP to the server
+as follows:
+
+GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
+QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA==
+ Liu/Madson/McGrew/Nourse [Page 13a]
+
+If supported by the CA, the message may also be sent via HTTP POST:
+
+POST /cgi-bin/pkiclient.exe?operation=PKIOperation
+
+This is further described in Appendix H.
+To determine if the CA supports POST, use the GetCACaps message described
+in Appendix F.
+
+
+3.2 Response Message Format
+
+For each GET operation, the CA/RA server will return a MIME object via
+HTTP. For a GET operation with PKIOperation as its type, the response is
+tagged as having a Content Type of application/x-pki-message. 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 the case of GET operation with a type of GetCACert the MIME content
+type returned will depend on whether or not an RA is in use. If there
+is no RA, only the CA certificate is sent back in the response, and
+the response has the content type tagged 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, the RA certificates are sent back together with the
+CA certificates, a certificate-only PKCS#7 SignedData is sent back in
+the response where the SignerInfo is empty. Section 5 has the detailed
+definition of the message format in this case. The content type is
+application/x-x509-ca-ra-cert.
+
+The response to GetNextCACert is always a certificates-only PKCS#7
+SignedData with a content type of application/x-x509-ca-ra-cert.
+If there is an RA, The signer is the current RA certificate. Otherwise,
+the signer is the current CA certificate.
+
+If the CA supports it, PKIOperation may also be done via an HTTP POST.
+This is described in Appendix H.
+
+ Liu/Madson/McGrew/Nourse [Page 14]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Section 4 Secure Transportation: PKCS#7
+
+PKCS#7 is a general enveloping mechanism that enables both signed and
+encrypted transmission of arbitrary data. It is widely implemented and
+included in the RSA tool kit. In this section, the general PKCS#7
+enveloped PKI message format is specified. The complete PKCS#7 message
+format for each PKI transaction will be covered in Section 5.
+
+4.1 SCEP Message Format
+
+As a transaction message, a SCEP message has a set of transaction
+specific attributes and an information portion. Employing PKCS#7
+protocol, the transaction specific attributes are encoded as a set of
+authenticated attributes of the SignedData. The information portion will
+first be encrypted to become Enveloped Data, and then the digest of the
+enveloped information portion is included as one of the message digest
+attributes and being signed together with the other transaction specific
+attributes.
+
+By applying both enveloping and signing transformations, 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 the conventional transaction message
+format is that, the signed transaction type information and the status
+of the transaction can be determined prior to invoke security handling
+procedures specific to the information portion being processed.
+
+The following is an example of a SCEP message with its enveloped and
+signed data portion represented by pkcsPKISigned and
+pkcsPKIEnveloped. The out-most of any PKI message is a blob of
+ContentInfo, with its content type set to SignedData and the actual
+signed data as the content.
+
+ Liu/Madson/McGrew/Nourse [Page 15]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ pkiMessage ContentInfo ::= {
+ contentType {pkcs-7 signedData(2)}
+ content pkcsPKISigned
+ }
+ pkcsPKISigned SignedData ::= {
+ version 1
+ digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1} -- data content identifier
+ content pkcsPKIEnvelope -- enveloped information portion
+ }
+ certificates -- signer certificate chain
+ signerInfo -- including signed transaction info and the digest
+ -- of the enveloped information portion as the
+ -- authenticated attributes
+ }
+ pkcsPKIEnveloped EnvelopedData ::= {
+ version 0
+ recipientInfos -- information required to open the envelop
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content identifier
+ contentEncryptionAlgorithm
+ encryptedContent -- encrypted information portion
+ }
+ }
+
+4.2 Signed Transaction Attributes
+
+The following transaction attributes are encoded as authenticated
+attributes. Please refer to Appendix B for the OID definitions.
+
+transactionID PrintableString -- Decimal value as a string
+ messageType PrintableString -- Decimal value as a string
+ pkiStatus PrintableString -- Decimal value as a string
+ failinfo PrintableString -- Decimal value as a string
+ senderNonce Octet String
+ recipientNonce Octet String
+
+where:
+
+ The transactionID is an attribute which uniquely identify a
+ transaction. This attribute is required in all PKI messages.
+
+ The messageType attribute specify the type of operation performed by the
+ transaction. This attribute is required in all PKI
+ messages. Currently, the following message types are defined:
+
+ PKCSReq (19) -- Permits use of PKCS#10 certificate request
+ CertRep (3) -- Response to certificate or CRL request
+ GetCertInitial (20) -- Certificate polling in manual enrollment
+ GetCert (21) -- Retrieve a certificate
+ GetCRL (22) -- Retrieve a CRL
+
+ Liu/Madson/McGrew/Nourse [Page 16]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+ All response message will include transaction status information which
+ is defined as pkiStatus attribute:
+
+ SUCCESS (0) -- request granted
+ FAILURE (2) -- request rejected
+ PENDING (3) -- request pending for manual approval.
+
+ If the status in the response is FAILURE, the failinfo attribute will
+ contain one of the following failure reasons:
+
+ badAlg (0) -- Unrecognized or unsupported algorithm ident
+ badMessageCheck (1) -- integrity check failed
+ badRequest (2) -- transaction not permitted or supported
+ badTime (3) -- Message time field was not sufficiently close
+ to the system time
+ badCertId (4) -- No certificate could be identified matching
+ the provided criteria
+
+ The attributes of senderNonce and recipientNonce are the 16 byte
+ random numbers generated for each transaction to prevent the replay
+ attack.
+
+When a requester sends a PKI message to the server, a senderNonce is
+included in the message. After the server processes the request, it will
+send back the requester senderNonce as the recipientNonce and generates
+another nonce as the senderNonce in the response message. Because the
+proposed pki protocol is a two-way communication protocol, it is clear
+that the nonce can only be used by the requester to prevent the
+replay. The server has to employ extra state related information to
+prevent a replay attack.
+
+Section 5. SCEP Transaction Specification
+
+In this 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 of one PKCSReq message
+sent to the certificate authority from a requester, and one CertRep
+message sent back from the server. The pkiStatus returned in the
+response message is either SUCCESS, or FAILURE, or PENDING. The
+information portion of a PKCSReq message is a PKCS#10 certificate
+request, which contains the subject Distinguished Name, the subject
+public key, and two attributes, a ChallengePassword attribute to be used
+for revocation, and an optional ExtensionReq attribute which will be a
+sequence of extensions the requester expects to be included in its V3
+certificate extensions. One of the extension attribute specifies the key
+usage. If the request is granted, the pkiStatus is set to SUCCESS, and
+the certificate is returned in CertRep; if the request is rejected, the
+
+
+ Liu/Madson/McGrew/Nourse [Page 17]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+pkiStatus is set to FAILURE; if the server requires manual approval of
+the request, the pkiStatus is set to PENDING. The messages exchanged
+in the manual authentication mode is further specified in Section 5.2.
+
+Precondition:
+ Both the requester and the certificate authority have completed their
+ initialization process. The requester has already been configured
+ with the CA/RA certificate.
+
+Postcondition:
+ Either the certificate is received by the requester, or the end
+ entity is notified to do the manual authentication, or the request
+ is rejected.
+
+5.1.1 PKCSReq Message Format
+
+A PKCSReq message is created by following the steps defined below:
+
+1. Create a PKCS#10 certificate request which is signed by the end
+ entity's private key, corresponding to the public key included in
+ the PKCS#10 certificate request. This constitutes the information
+ portion of PKCSReq.
+
+2. Encrypt the PKCS#10 certificate request using a randomly generated
+ content-encryption key. This content-encryption key is then
+ encrypted by the CA's* public key and included in the recipientInfo.
+ This step completes the "envelope" for the PKCS#10 certificate
+ request.
+
+3. Generate a unique string as the transaction id.
+
+4. Generate a 16 byte random number as senderNonce.
+
+5. Generate message digest on the enveloped PKCS#10 certificate request
+ using the selected digest algorithm.
+
+6. Create SignedData by adding the requester's self- or CA-certificate
+ as the signer's public key certificate. Include the message type,
+ transaction id, the senderNonce and the message digest as the
+ authenticated attributes and sign the attributes using the end
+ entity's private key. This completes the SignedData.
+
+7. The SignedData is prepended with the ContenInfo blob which indicates
+ a SignedData object. This final step completes the create of a
+ complete PKCSReq PKI message.
+
+In the following, the PKCSReq message is defined following the ASN.1
+notation.
+
+For readability, the values of a field is either represented by a quoted
+string which specifies the intended value, or a constant when the value
+is known.
+
+
+ Liu/Madson/McGrew/Nourse [Page 18]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ -- PKCSReq information portion
+ pkcsCertReq CertificationRequest ::= { -- PKCS#10
+ version 0
+ subject "the requester's subject name"
+ subjectPublicKeyInfo {
+ algorithm {pkcs-1 1} -- rsa encryption
+ subjectPublicKey "DER encoding of the requester's public key"
+ }
+ attributes {
+ challengePassword {{pkcs-9 7} "password string" }
+ extensions
+ }
+ signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption
+ signature "bit string which is created by signing inner content
+ of the defined pkcsCertReq using requester's private
+ key, corresponding to the public key included in
+ subjectPublicKeyInfo."
+ }
+ -- Enveloped information portion
+ pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber {
+ issuer "the CA issuer name"
+ serialNumber "the CA certificate serial number"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption
+ encryptedKey "content-encryption key
+ encrypted by CA public key"
+ }
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content
+ contentEncryptionAlgorithm "object identifier
+ for DES encryption"
+ encryptedContent "encrypted pkcsCertReq using the content-
+ encryption key"
+ }
+ }
+ -- Signed PKCSReq
+ pkcsCertReqSigned SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1} -- data content identifier
+ content pkcsCertReqEnvelope
+ }
+ certificate { -- requester self-signed or CA-issued certificate
+ version 3
+ serialNumber "the transaction id associated with enrollment"
+ signature {pkcs-1 4} -- md5WithRSAEncryption
+
+
+ Liu/Madson/McGrew/Nourse [Page 19]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ issuer " the requester's subject name"
+ validity {
+ notBefore "a UTC time"
+ notAfter "a UTC time"
+ }
+ subject "the requester's subject name"
+ subjectPublicKeyInfo {
+ algorithm {pkcs-1 1}
+ subjectPublicKey "DER encoding of requester's public key"
+ }
+ signatureAlgorithm {pkcs-1 4}
+ signature "the signature generated by using the requester's
+ private key corresponding to the public key in
+ this certificate."
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "the requester's subject name"
+ serialNumber "the transaction id associated
+ with the enrollment"
+ }
+ digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} "an octet string"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ -- this transaction id will be used
+ -- together with the subject name as
+ -- the identifier of the requester's key
+ -- pair during enrollment
+ messageType {{id-attributes messageType(2)} "PKCSReq"}
+ senderNonce {{id-attributes senderNonce(5)}
+ "a random number encoded as a string"}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption
+ encryptedDigest "encrypted digest of the authenticated
+ attributes using requester's private key"
+ }
+ }
+ pkcsReq PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content pkcsCertRepSigned
+ }
+
+
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 20]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+5.1.2 CertRep Message Format
+
+The response to an SCEP enrollment request is a CertRep message.
+
+5.1.2.1 PENDING Response
+
+When the CA is configured to manually authenticate the requester,
+the CertRep is returned with the attribute pkiStatus set to PENDING.
+The data portion for this message is null. Only the transaction
+required attributes are sent back.
+
+CertRepSigned SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {contentType {pkcs-7 1} -- empty content
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "name of CA that issued the CA [RA] cert"
+ serialNumber "the serial number of the CA [RA] cert"
+ }
+ digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} NULL}
+ messageType {{id-attribute messageType(0)} "CertRep"}
+ transaction-id {{id-attributes transid(7)} "printablestring"}
+ --- same transaction id used in PKCSReq
+ pkiStatus {{id-attributes pkiStatus(3)} "PENDING"}
+ recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>}
+ senderNonce {{id-attributes senderNonce(5)} <16 bytes>}
+ }
+ digestEncrytionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted message digest of the authenticated
+ attributes using the CA's [RA's] private key"
+ }
+}
+CertRep PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content CertRepSigned
+}
+
+5.1.2.2 Failure Response
+
+In this case, the CertRep sent back to the requester is same as in
+the PENDING case, except that the pkiStatus attribute is set to FAILURE,
+and the failInfo attribute should be included:
+
+ pkistatus {{id-attributes pkiStatus(3)} "FAILURE"}
+ failInfo {{id-attributes failInfo(4)} "the reason to reject"}
+
+ Liu/Madson/McGrew/Nourse [Page 21]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+5.1.2.3 SUCCESS response
+
+In this case, the information portion of CertRep will be a degenerated
+PKCS#7 which contains the requester's certificate. It is then enveloped
+and signed as below:
+
+pkcsCertRep SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo { -- empty content since this is degenerated PKCS#7
+ contentType {pkcs-7 1}
+ }
+ certificates {
+ certificate { -- issued requester's certificate // must be first
+ version 3
+ serialNumber "issued requester's certificate serial number"
+ signature {pkcs-1 4} -- md5WithRSAEncryption
+ issuer "the certificate authority issuer name"
+ validity {
+ notBefore "UTC time"
+ notAfter "UTC time"
+ }
+ subject "the requester subject name as given in PKCS#10"
+ subjectPublicKeyInfo {
+ algorithm {pkcs-1 1}
+ subjectPublicKey "a DER encoding of requester public
+ key as given in PKCS#10"
+ }
+ extensions " the extensions as given in PKCS#10"
+ signatureAlgorithm {pkcs-1 4}
+ signature " the certificate authority signature"
+ }
+ certificate "the certificate authority certificate" (optional)
+ certificate "the registration authority certificate(s)" (optional)
+ }
+}
+pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber { -- use issuer name and serial number as
+ -- conveyed in requester's self-signed
+ -- certificate, included in the PKCSReq
+ issuer "the requester's subject name"
+ serialNumber "the serial number defined by the requester in
+ its self-signed certificate"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1}
+ encryptedKey "content-encrypt key encrypted by the requester's
+ public key which is same key as authenticated in
+ the requester's certificate"
+ }
+
+
+ Liu/Madson/McGrew/Nourse [Page 22]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content identifier
+ contentEncryptionAlgorithm "OID for DES encryption"
+ encryptedContent "encrypted pkcsCertRep using content encryption
+ key"
+ }
+}
+pkcsCertRepSigned SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+ content pkcsCertRepEnvelope
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "the certificate authority issuer name"
+ serialNumber "the CA certificate's serial number"
+ }
+ digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} "a octet string"}
+ messageType {{id-attribute messageType(2)} "CertRep"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ -- same transaction id as given in PKCSReq
+ pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"}
+ recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>}
+ senderNonce {{ id-attributes senderNonce(5) <16 bytes>}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted digest of authenticate attributes
+ using CA's private key "
+ }
+}
+CertRep PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content pkcsCertRepSigned
+}
+
+5.2 Poll for Requester Initial Certificate
+
+Either triggered by the PENDING status received from the CertRep, or by
+the non-response timeout for the previous PKCSReq, a requester will
+enter the polling state by periodically sending GetCertInitial 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 is exceeded.
+
+
+ Liu/Madson/McGrew/Nourse [Page 23]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+Since GetCertInitial is part of the enrollment, the messages exchanged
+during the polling period should carry the same transaction identifier
+as the previous PKCSReq.
+
+PreCondition
+ Either the requester has received a CertRep with pkiStatus set to be
+ PENDING, or the previous PKCSReq has timed out.
+
+PostContition
+ The requester has either received the certificate, or be rejected of
+ its request, or the polling period ended as a failure.
+
+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, combined with the
+transaction identifier, 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).
+
+-- Information portion
+
+pkcsGetCertInitial issuerAndSubject ::= {
+ issuer "the certificate authority issuer name"
+ subject "the requester subject name as given in PKCS#10"
+}
+pkcsGetCertInitialEnvelope EnvelopedData ::= {
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber {
+ issuer "the CA issuer name"
+ serialNumber "the CA certificate serial number"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1}
+ encryptedKey "content-encrypt key encrypted by CA's public key"
+ }
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content
+ contentEncryptionAlgorithm "OID for DES encryption"
+ encryptedContent "encrypted getCertInital"
+ }
+}
+pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+
+
+ Liu/Madson/McGrew/Nourse [Page 24]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ content pkcsGetCertIntialEnvelope
+ }
+ certificate { -- the requester's self-signed certificate
+ version 3
+ serialNumber "the transaction id associated with enrollment"
+ signature {pkcs-1 4} -- md5WithRSAEncryption
+ issuer " the requester's subject name"
+ validity {
+ notBefore "a UTC time"
+ notAfter "a UTC time"
+ }
+ subject "the requester's subject name"
+ subjectPublicKeyInfo {
+ algorithm {pkcs-1 1}
+ subjectPublicKey "DER encoding of requester's public key"
+ }
+ signatureAlgorithm {pkcs-1 4}
+ signature "the signature generated by using the requester's
+ private key corresponding to the public key in
+ this certificate."
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "requester's subject name"
+ serialNumber "the transaction id used in previous PKCSReq"
+ }
+ digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} "an octet string"}
+ -- digest of getCertInitial
+ messageType {{id-attribute messageType(2)} "GetCertInitial"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ -- same transaction idused in previous PKCSReq
+ senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted digest of authenticateAttributes"
+ }
+}
+GetCertInitial PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content pkcsGetCertInitialSigned
+}
+
+
+
+5.2.2 GetCertInitial Response Message Format
+
+The response messages for GetCertInitial are the same as for PKCSReq.
+
+ Liu/Madson/McGrew/Nourse [Page 25]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+5.3 Certificate Access
+
+The certificate query message defined in this section is an option when
+the LDAP server is not available to provide the certificate query. A
+requester should be able to query an issued certificate from the
+certificate 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 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 the
+self-signed certificate has to be included in the signed envelope.
+
+ pkcsGetCert issuerAndSerialNumber ::= {
+ issuer "the certificate issuer name"
+ serialNumber "the certificate serial number"
+ }
+ pkcsGetCertEnvelope EnvelopedData ::= {
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber {
+ issuer "the CA [RA] issuer name"
+ serialNumber "the CA [RA] certificate serial number"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1}
+ encryptedKey "content-encrypt key encrypted
+ by CA [RA] public key"
+ }
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 26]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content
+ contentEncryptionAlgorithm "OID for DES encryption"
+ encryptedContent "encrypted pkcsGetCert using the content
+ encryption key"
+ }
+ }
+ pkcsGetCertSigned SignedData ::= {
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+ content pkcsGetCertEnvelope
+ }
+ certificates {
+ certificate "CA issued certificate"
+ or "self-signed certificate"
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "the requester's subject name"
+ serialNumber "requester's certificate serial number"
+ }
+ digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} "an octet string"}
+ -- digest of pkcsGetCertEnvelope
+ messageType {{id-attribute messageType(2)} "GetCert"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted digest of authenticateAttributes"
+ }
+ }
+ GetCert PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content pkcsGetCertSigned
+ }
+
+
+
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 27]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+5.3.2 CertRep Message Format
+
+In this case, the CertRep from the server is same as the CertRep for the
+PKCSReq, except that the server will only either grant the request or
+reject the request. Also, the recipientInfo should use the CA issuer
+name and CA assigned serial number to identify the requester's key pair
+since at this time, the requester has received its own certificate.
+
+5.4 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 here, only the requester can initiate the transaction to
+download CRL. A requester sends GetCRL request to the server and the
+server sends back CertRep whose information portion is a degenerated
+PKCS#7 which contains only the most recent CRL. The size of CRL included
+in the CertRep should be determined by the implementation.
+
+PreCondition
+ The certificate authority certificate has been downloaded to the end
+ entity.
+
+PostCondition
+ CRL sent back to the requester.
+
+5.4.1 GetCRL Message format
+
+The CRL is identified by using both CA's issuer name and the CA
+certificate's serial number:
+
+ pkcsGetCRL issuerAndSerialNumber {
+ issuer "the certificate authority issuer name"
+ serialNumber "certificate authority certificate's serial number"
+ }
+
+When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as
+the following:
+
+ pkcsGetCRL SEQUENCE {
+ crlIssuer issuerAndSerialNumber
+ distributionPoint CE-CRLDistPoints
+ }
+
+where CE-CRLDisPoints is defined in X.509, but must contain only one
+CRL distribution point.
+
+
+
+
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 28]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ pkcsGetCRLEnvelope EnvelopedData ::= {
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber {
+ issuer "the certificate authority (or RA) issuer name"
+ serialNumber "the CA (RA) certificate's serial number"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1}
+ encryptedKey "content-encrypt key encrypted by CA (RA) public key"
+ }
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content
+ contentEncryptionAlgorithm "OID for DES encryption"
+ encryptedContent "encrypted pkcsGetCRL"
+ }
+ }
+ pkcsGetCRLSigned SignedData ::= {
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+ content pkcsGetCRLEnvelope
+ }
+ certificates {
+ certificate "CA-issued or self-signed requester's certificate"
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "the requester's issuer name"
+ serialNumber "the requester's certificate serial number"
+ }
+ digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} 0x<16/20 bytes>}
+ -- digest of pkcsGetCRLEnvelope
+ messageType {{id-attribute messageType(2)} "CertCRL"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted digest of authenticateAttributes"
+ }
+ }
+ GetCRL PKIMessage ::= {
+ contentType {pkcs-7 2}
+ content pkcsGetCRLSigned
+ }
+
+ Liu/Madson/McGrew/Nourse [Page 29]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+5.4.2 CertRep Message Format
+
+The CRL is sent back to the requester through CertRep message. The
+information portion of this message is a degenerated PKCS#7 SignedData
+which contains only a CRL.
+
+ pkcsCertRep SignedData ::= {
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+ }
+ crl {
+ signature {pkcs-1 4}
+ issuer "the certificate authority issuer name"
+ lastUpdate "UTC time"
+ nextUpdate "UTC time"
+ revokedCertificate {
+ -- the first entry
+ userCertificate "certificate serial number"
+ revocationData "UTC time"
+ ....
+ -- last entry
+ userCertificate "certificate serial number"
+ revocationData "UTC time"
+ }
+ }
+ pkcsCertRepEnvelope EnvelopedData ::= {
+ version 0
+ recipientInfo {
+ version 0
+ issuerAndSerialNumber {
+ issuer "the requester's issuer name"
+ serialNumber "the requester certificate serial number"
+ }
+ keyEncryptionAlgorithm {pkcs-1 1}
+ encryptedKey "content-encrypt key encrypted by requester's
+ public key "
+ }
+ encryptedContentInfo {
+ contentType {pkcs-7 1} -- data content
+ contentEncryptionAlgorithm "OID for DES encryption"
+ encryptedContent "encrypted pkcsCertRep using requester's
+ public key"
+ }
+ }
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 30]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+ pkcsCertRepSigned SignedData ::= { -- PKCS#7
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ contentInfo {
+ contentType {pkcs-7 1}
+ content pkcsCertRepEnvelope
+ }
+ signerInfo {
+ version 1
+ issuerAndSerialNumber {
+ issuer "the certificate authority issuer name"
+ serialNumber "the CA certificate's serial number"
+ }
+ digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+ authenticateAttributes {
+ contentType {{pkcs-9 3} {pkcs-7 1}}
+ messageDigest {{pkcs-9 4} "an octet string"}
+ -- digest of pkcsCertRepEnvelope
+ messageType {{id-attribute messageType(2)} "CertRep"}
+ transaction-id {{id-attributes transId(7)} "printable
+ string"}
+ -- same transaction id as given in PKCSReq
+ pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"}
+ recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>}
+ senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>}
+ }
+ digestEncryptionAlgorithm {pkcs-1 1}
+ encryptedDigest "encrypted digest of authenticatedAttributes
+ using CA private key"
+ }
+ }
+
+
+NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but
+SCEP entities must also accept a sequence of octet strings as a valid
+alternate encoding.
+
+This alternate encoding must be accepted wherever PKCS #7 Enveloped
+Data is specified in this document.
+
+
+
+
+
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 31]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+5.5 Get Certificate Authority Certificate
+
+Before any transaction begins, end entities have to get the CA (and
+possibly RA) certificate(s) first. Since the requester may have no CA
+certificates or CA public keys at all, this message can not be
+encrypted and the response must be authenticated by out-of-band means.
+These certs are obtained by means of an HTTP GET message. To get the
+CA certificate, the requester does a "HTTP GET" with a URL that
+identifies a CGI script on the server and an optional CA issuer
+identifier as the parameter to the CGI script. The response is either
+a single X.509 CA certificate ("CA mode"), or a PKCS7 message
+containing the CA certificate and RA certificates ("RA mode"). The
+client can determine which mode the CA operates in by which response
+it gets. Once the CA certificate is received by the requester, a
+fingerprint is generated using either the SHA-1 or the MD5 hash
+algorithm on the whole CA certificate. If the requester does not have
+a certificate path to a trusted CA certificate, this fingerprint may
+be used to verify the certificate, by some positive out-of-band means,
+such as a phone call.
+
+5.5.1 GetCACert HTTP Message Format
+ "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT
+ where:
+ CGI-PATH defines the actual CGI path to invoke the CGI program
+ which parses the request.
+ CGI-PROG is set to be the string "pkiclient.exe" and this is
+ expected to be the program that the CA will use to handle the
+ SCEP transactions.
+ CA-IDENT is any string which is understood by the CA.
+ For example, it could be a domain name like ietf.org.
+ If a certificate authority has multiple CA certificates
+ this field can be used to distinguish which is required.
+ Otherwise it may be ignored.
+
+5.5.2 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.
+
+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 SignedData is used to
+carry the certificates to the requester, with a Content-Type of
+application/x-x509-ca-ra-cert.
+
+ Liu/Madson/McGrew/Nourse [Page 32]
+
+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 certificates-only message containing
+a CA certificate (and possibly RA certificates) to be used when the current CA
+certificate expires, signed with the current CA cert (or RA certificate, if
+the CA is in RA mode. Note that a PKCS#7 is returned even in 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. The response is a list of
+text capabilities, as defined in Appendix F. Support for this message
+is optional, but if it is not supported, the client should assume that
+none of the capabilities in Appendix F are supported.
+
+5.6 Get Certificate Authority Certificate Chain
+
+GetCACertChain provides a way 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 Response
+
+The response for GetCACertChain is a certificates-only PKCS#7 SignedData
+to carry the certificates to the requester, with a Content-Type of
+application/x-x509-ca-ra-cert-chain.
+
+5.6.3 Backwards Compatability
+
+Versions of SCEP prior to revision 3 do not support GetCACertChain.
+Certificate Authorities written to these prior versions will not be
+able 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 or is signed by a Certificate
+Authority that is trusted by the client, then it is not necessary to
+send the GetCACertChain message and it should not be sent.
+
+If a Certificate Authority is configured with a certificate that is
+not either self-signed or has a self-signed issuer, then it should
+support this message. In other words, it should be supported if the
+CA hierarchy is more than two-deep.
+
+An old CA in a two-deep hierarchy might still get this message from
+a client if the client did not trust either that CA or its issuer.
+In that event, the certificate cannot be trusted anyway. In any case
+the CA must not crash or hang upon the receipt of the message and the
+client must be able to handle whatever error is returned by the CA,
+including an HTML error or an ungraceful disconnect.
+
+ Liu/Madson/McGrew/Nourse [Page 33]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+The following is the ASN.1 definition of Cert-Only PKCS#7:
+
+ certOnly SignedData ::= {
+ version 1
+ digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
+ digestAlgorithm(2) 5}
+
+contentInfo {
+ contentType {pkcs-7 1} -- data content identifier
+ content -- NULL
+ }
+ certificates -- the RA and CA certificates.
+ }
+
+ CARACerts PKIMessage ::= { -- special pki message sent in the clear
+ contentType {pkcs-7 2}
+ content certOnly
+ }
+
+
+6.0 Security Considerations
+
+This entire document is about security. Common security 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.
+
+
+7.0 Intellectual Property
+
+This protcol 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.
+
+
+8.0 References
+
+[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
+1.5", RFC 2315, March 1998.
+
+[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version
+1.5", RFC 2314, March 1998.
+
+[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key
+Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 34]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+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 binded 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"}
+
+
+ Liu/Madson/McGrew/Nourse [Page 35]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Appendix B: IPSEC Client Enrollment Certificate Request
+
+The following is the certificate enrollment request (PKCS#10) 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
+ : }
+ 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
+
+
+ Liu/Madson/McGrew/Nourse [Page 36]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ 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
+ : }
+
+
+Appendix C: Private OID Definitions
+
+The OIDs used in defining pkiStatus are VeriSign self-maintained
+OIDs. Please note, work is in progress to replace the VeriSign owned
+object identifiers with the standard object identifiers. Once the
+standarlization is completed, this documentation will be updated.
+
+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)}
+
+
+ Liu/Madson/McGrew/Nourse [Page 37]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+ 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
+
+
+
+Appendix E: SCEP State Transitions
+
+SCEP state transitions are based on transaction identifier. 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 the client named as Alice.cisco.com plus IPAddress 117.96.1.219.
+
+Each enrollment transaction is uniquely associated with a transaction
+identifier. 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 idenifier. 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
+
+
+ Liu/Madson/McGrew/Nourse [Page 38]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+key pair binding. In the current implementation, an SCEP client can
+only assume one identity. At any time, only one key pair, with a given
+key usage, can be associated with the same identity.
+
+The following gives several examples of client to CA transactions.
+
+Client actions are indicated in the left column, CA actions are
+indicated in the right column. A blank action signifies that no message
+was received. Note that these examples assume that the CA enforces the
+certificate-name uniqueness property defined in Section 2.1.1.1.
+
+The first transaction, for example, would read like this:
+ "Client Sends PKCSReq message with transaction ID 1 to the
+ CA. The CA signs the certificate and constructs a CertRep Message
+ containing the signed certificate with a transaction ID 1. The client
+ receives the message and installs the cert 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
+GetCertInitial (3) ----------->
+ <----------- CA signed Cert and sent back
+ CertRep(3)
+(Time Out)
+PKCSReq (3) ----------> Cert already signed, sent back to
+ client
+Client Installs Cert <---------- CertRep (3) SIGNED CERT
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 39]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+
+Case when NVRAM is lost and client has to generate a new key pair, there
+is no change of name information:
+
+PKCSReq (4) ----------> CA Signs Cert
+Client Installs Cert <---------- CertRep (4) SIGNED CERT
+(Client looses Cert)
+PKCSReq (5) ----------> There is already a valid cert with
+ this DN.
+Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR
+PKCSReq (5) ----------> CA Signs Cert
+Client Installs Cert <---------- CertRep (5) SIGNED CERT
+
+
+Case when client admin resync the enrollment using a different PKCS#10:
+PKCSReq (6) ----------> CA Signs Cert
+ <---------- CertRep (6) SIGNED CERT
+(Client timeout and admin starts another enrollment with a different
+ PKCS#10, but the same transaction id)
+PKCSReq (6) with different PKCS#10
+ ----------> There is already a valid cert with
+ this entity (by checking FQDN).
+ <---------- CertRep (6) INVALID PKCS#10 CERT
+ ERROR
+Client admin either revokes the existing cert
+or corrects the error by enrolling with
+the same PKCS#10 as the first PKCSReq(6)
+PKCSReq (6) ----------> CA find the existing Cert
+Client Installs Cert <---------- CertRep (6) SIGNED CERT
+
+
+Resync case when server is slow in response:
+PKCSReq (13) ----------> Cert Request goes into Queue
+ <---------- CertRep (13) PENDING
+GetCertInitial ----------> Still pending
+ <---------- CertRep (13) PENDING
+GetCertInitial ----------> Still pending
+ <---------- CertRep (13) PENDING
+GetCertInitial ----------> Still pending
+ <---------- CertRep (13) PENDING
+GetCertInitial ----------> Still pending
+(TimeOut) <---------- CertRep (13) PENDING
+* Case 1
+PKCSReq (13) ----------> Still pending
+Client polls <---------- CertRep (13) PENDING
+CertCertInitial ----------> Cert has been signed
+Client Installs Cert <---------- CertRep (13) SIGNED CERT
+* Case 2
+PKCSReq (13) ----------> Cert has been signed
+Client Installs Cert <---------- CertRep (13) SIGNED CERT
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 40]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Appendix F. CA Capabilities
+
+The response for a GetCACaps message is a list of CA capabilities, in
+plain text, separated by <LF> characters, as follows (quotation marks
+are NOT sent):
+
+Keyword Description
+
+"GetNextCACert" CA Supports the GetNextCACert message.
+"POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST.
+"SHA-1" CA Supports the SHA-1 hashing algorithm in
+ signatures and fingerprints. If present, the
+ client SHOULD use SHA-1. If absent, the client
+ MUST use MD5 to maintain backward compatability.
+"Renewal" Clients may use current certificate and key to
+ authenticate an enrollment request for a new
+ certificate.
+
+A client must be able to accept and ignore any unknown keywords that
+might be sent back by a CA that implements a future version of SCEP.
+
+Example:
+
+GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca
+
+returns:
+
+GetNextCACert
+POSTPKIOperation
+
+This means that the CA supports the GetNextCACert message and allows
+PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent
+using HTTP POST.
+
+
+ Liu/Madson/McGrew/Nourse [Page 41]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Appendix G. 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:
+
+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.
+existing cert expires.
+
+
+*enveloped for new CA or RA cert and keypair. The CA will use the
+envelope to determine which key and certificate to use to issue the
+client certificate.
+
+
+ Liu/Madson/McGrew/Nourse [Page 42]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Appendix H. PKIOperation via HTTP POST Message
+
+If the remote CA supports it, any of the PKCS#7-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
+<binary PKCS7 data>
+
+The client can verify that the CA supports SCEP messages via POST by
+looking for the "POSTPKIOperation" capability (See Appendix F).
+
+
+
+
+
+
+ Liu/Madson/McGrew/Nourse [Page 43]
+
+Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
+
+Appendix Y. Author Contact Information
+
+Xiaoyi Liu Cheryl Madson
+Cisco Cisco
+510 McCarthy Drive 510 McCarthy Drive
+Milpitas, CA Milpitas, CA.
+xliu@cisco.com cmadson@cisco.com
+
+
+David McGrew Andrew Nourse
+Cisco Cisco
+170 West Tasman Drive 510 McCarthy Drive
+San Jose, CA 94134 Milpitas, CA.
+mcgrew@cisco.com nourse@cisco.com
+
+
+
+
+Appendix Z. Copyright Section
+
+Copyright (C) The Internet Society (2005). This document is subject
+to the rights, licenses and restrictions contained in BCP 78, and
+except as set forth therein, the authors retain all their rights.
+
+This document and the information contained herein are provided on an
+"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+This draft expires 11 Aug 2005
+
+[End of draft-nourse-scep-11.txt]
+
diff -uN sscep/fileutils.c sscep-ng2/fileutils.c
--- sscep/fileutils.c 2003-04-15 12:53:45.000000000 +0200
+++ sscep-ng2/fileutils.c 2006-04-28 10:03:24.000000000 +0200
@@ -55,8 +55,11 @@
PKCS7 *p7;
STACK_OF(X509) *certs;
X509 *cert = NULL;
+ ASN1_BIT_STRING *cert_pubkey = NULL;
FILE *fp;
int i;
+ ASN1_BIT_STRING *request_pubkey =
+ request->req_info->pubkey->public_key;
localcert = NULL;
@@ -66,29 +69,44 @@
/* Find cert */
for (i = 0; i < sk_X509_num(certs); i++) {
- char buffer[1024];
-
cert = sk_X509_value(certs, i);
+ cert_pubkey = X509_get_X509_PUBKEY(cert)->public_key;
+#define fu_print_name(n) \
+ X509_NAME_print_ex_fp(stdout,(n),0,XN_FLAG_RFC2253|ASN1_STRFLGS_SHOW_TYPE)
if (v_flag) {
- printf("%s: found certificate with\n"
- " subject: %s\n", pname,
- X509_NAME_oneline(X509_get_subject_name(cert),
- buffer, sizeof(buffer)));
- printf(" issuer: %s\n",
- X509_NAME_oneline(X509_get_issuer_name(cert),
- buffer, sizeof(buffer)));
+ printf("%s: found certificate with\n subject: ", pname);
+ fu_print_name(X509_get_subject_name(cert));
+ printf("\n issuer: ");
+ fu_print_name(X509_get_issuer_name(cert));
+ printf("\n");
}
- /* The subject has to match that of our request */
- if (!X509_NAME_cmp(X509_get_subject_name(cert),
+ /* The public keys of the request and certificate must match */
+ if (M_ASN1_BIT_STRING_cmp(request_pubkey,cert_pubkey) != 0) {
+ if (v_flag)
+ printf(" public keys of request and certificate don't match\n");
+ continue;
+ }
+ /* The subject has to match that of our request,
+ if the "Compare subject DN" flag is set */
+ if (C_flag && X509_NAME_cmp(X509_get_subject_name(cert),
X509_REQ_get_subject_name(request))) {
-
- /* The subject cannot be the issuer (selfsigned) */
- if (X509_NAME_cmp(X509_get_subject_name(cert),
- X509_get_issuer_name(cert))) {
- localcert = cert;
- break;
+ if (v_flag) {
+ printf(" certificate subject names doesn't match request subject name:\n ");
+ fu_print_name(X509_REQ_get_subject_name(request));
+ printf("\n");
}
- }
+ continue;
+ }
+#undef fu_print_name
+ /* The subject cannot be the issuer (selfsigned) */
+ if (!X509_NAME_cmp(X509_get_subject_name(cert),
+ X509_get_issuer_name(cert))) {
+ if (v_flag)
+ printf(" certificate is self signed\n");
+ continue;
+ }
+ localcert = cert;
+ break;
}
if (localcert == NULL) {
fprintf(stderr, "%s: cannot find requested certificate\n",
@@ -320,34 +338,36 @@
/* Read local certificate (GetCert and GetCrl) */
void
-read_local_cert(void) {
- if (!l_flag || !(localfile = fopen(l_char, "r"))) {
- fprintf(stderr, "%s: cannot open local cert file\n", pname);
+read_cert(X509** cert, char* filename) {
+ FILE *file;
+ if (!(file = fopen(filename, "r"))) {
+ fprintf(stderr, "%s: cannot open cert file %s\n", pname, filename);
exit (SCEP_PKISTATUS_FILE);
}
- if (!PEM_read_X509(localfile, &localcert, NULL, NULL)) {
- fprintf(stderr, "%s: error while reading local cert\n", pname);
+ if (!PEM_read_X509(file, cert, NULL, NULL)) {
+ fprintf(stderr, "%s: error while reading cert %s\n", pname, filename);
ERR_print_errors_fp(stderr);
exit (SCEP_PKISTATUS_FILE);
}
- fclose(localfile);
+ fclose(file);
}
/* Read private key */
void
-read_key(void) {
+read_key(EVP_PKEY** key, char* filename) {
+ FILE *file;
/* Read private key file */
- if (!k_flag || !(keyfile = fopen(k_char, "r"))) {
- fprintf(stderr, "%s: cannot open private key file\n", pname);
+ if (!(file = fopen(filename, "r"))) {
+ fprintf(stderr, "%s: cannot open private key file %s\n", pname, filename);
exit (SCEP_PKISTATUS_FILE);
}
- if (!PEM_read_PrivateKey(keyfile, &rsa, NULL, NULL)) {
- fprintf(stderr, "%s: error while reading private key\n", pname);
+ if (!PEM_read_PrivateKey(file, key, NULL, NULL)) {
+ fprintf(stderr, "%s: error while reading private key %s\n", pname, filename);
ERR_print_errors_fp(stderr);
exit (SCEP_PKISTATUS_FILE);
}
- fclose(keyfile);
+ fclose(file);
}
/* Read PKCS#10 request */
diff -uN sscep/init.c sscep-ng2/init.c
--- sscep/init.c 2003-01-31 10:07:16.000000000 +0100
+++ sscep-ng2/init.c 2006-04-28 10:11:40.000000000 +0200
@@ -61,6 +61,9 @@
if (!(i_char = strdup(str2)))
error_memory();
}
+ } else if (!strncmp(str1, "CheckSubjectName", 16)) {
+ if (!strncmp(str2, "yes", 3) && !C_flag)
+ C_flag = 1;
} else if (!strncmp(str1, "CertReqFile", 11)) {
if (!r_flag) {
r_flag = 1;
@@ -114,6 +117,12 @@
if (!(l_char = strdup(str2)))
error_memory();
}
+ } else if (!strncmp(str1, "SignCertFile", 12)) {
+ if (!O_flag) {
+ O_flag = 1;
+ if (!(O_char = strdup(str2)))
+ error_memory();
+ }
} else if (!strncmp(str1, "MaxPollCount", 12)) {
if (!n_flag) {
n_flag = 1;
@@ -130,6 +139,12 @@
if (!(k_char = strdup(str2)))
error_memory();
}
+ } else if (!strncmp(str1, "SignKeyFile", 11)) {
+ if (!K_flag) {
+ K_flag = 1;
+ if (!(K_char = strdup(str2)))
+ error_memory();
+ }
} else if (!strncmp(str1, "SelfSignedFile", 15)) {
if (!L_flag) {
L_flag = 1;
diff -uN sscep/pkcs7.c sscep-ng2/pkcs7.c
--- sscep/pkcs7.c 2003-02-10 06:04:48.000000000 +0100
+++ sscep-ng2/pkcs7.c 2006-04-26 13:40:34.000000000 +0200
@@ -28,7 +28,8 @@
PKCS7 *p7enc;
PKCS7_SIGNER_INFO *si;
STACK_OF(X509_ATTRIBUTE) *attributes;
- X509 *signer = NULL;
+ X509 *signercert = NULL;
+ EVP_PKEY *signerkey = NULL;
/* Create a new sender nonce for all messages
* XXXXXXXXXXXXXX should it be per transaction? */
@@ -47,7 +48,8 @@
s->request_type_str = SCEP_REQUEST_PKCSREQ_STR;
/* Signer cert */
- signer = s->selfsigned;
+ signercert = s->signercert;
+ signerkey = s->signerkey;
/* Create inner PKCS#7 */
if (v_flag)
@@ -71,7 +73,8 @@
s->request_type_str = SCEP_REQUEST_GETCERTINIT_STR;
/* Signer cert */
- signer = s->selfsigned;
+ signercert = s->signercert;
+ signerkey = s->signerkey;
/* Create inner PKCS#7 */
if (v_flag)
@@ -95,7 +98,8 @@
s->request_type_str = SCEP_REQUEST_GETCERT_STR;
/* Signer cert */
- signer = localcert;
+ signercert = localcert;
+ signerkey = rsa;
/* Read data in memory bio */
databio = BIO_new(BIO_s_mem());
@@ -115,7 +119,8 @@
s->request_type_str = SCEP_REQUEST_GETCRL_STR;
/* Signer cert */
- signer = localcert;
+ signercert = localcert;
+ signerkey = rsa;
/* Read data in memory bio */
databio = BIO_new(BIO_s_mem());
@@ -217,9 +222,9 @@
}
/* Add signer certificate and signature */
- PKCS7_add_certificate(s->request_p7, signer);
+ PKCS7_add_certificate(s->request_p7, signercert);
if ((si = PKCS7_add_signature(s->request_p7,
- signer, rsa, sig_alg)) == NULL) {
+ signercert, signerkey, sig_alg)) == NULL) {
fprintf(stderr, "%s: error adding PKCS#7 signature\n", pname);
ERR_print_errors_fp(stderr);
exit (SCEP_PKISTATUS_P7);
@@ -317,7 +322,8 @@
STACK_OF(X509_ATTRIBUTE) *attribs;
char *p;
unsigned char buffer[1024];
- X509 *recipient;
+ X509 *recipientcert;
+ EVP_PKEY *recipientkey;
/* Create new memory BIO for outer PKCS#7 */
memorybio = BIO_new(BIO_s_mem());
@@ -547,10 +553,14 @@
/* Decrypt the inner PKCS#7 */
if ((s->request_type == SCEP_REQUEST_PKCSREQ) ||
- (s->request_type == SCEP_REQUEST_GETCERTINIT))
- recipient = s->selfsigned;
- else
- recipient = localcert;
+ (s->request_type == SCEP_REQUEST_GETCERTINIT)) {
+ recipientcert = s->signercert;
+ recipientkey = s->signerkey;
+ }
+ else {
+ recipientcert = localcert;
+ recipientkey = rsa;
+ }
if (v_flag)
printf("%s: reading inner PKCS#7\n",pname);
p7enc = d2i_PKCS7_bio(outbio, NULL);
@@ -568,7 +578,7 @@
outbio = BIO_new(BIO_s_mem());
if (v_flag)
printf("%s: decrypting inner PKCS#7\n",pname);
- if (PKCS7_decrypt(p7enc, rsa, recipient, outbio, 0) == 0) {
+ if (PKCS7_decrypt(p7enc, recipientkey, recipientcert, outbio, 0) == 0) {
fprintf(stderr, "%s: error decrypting inner PKCS#7\n", pname);
ERR_print_errors_fp(stderr);
exit (SCEP_PKISTATUS_P7);
diff -uN sscep/sceputils.c sscep-ng2/sceputils.c
--- sscep/sceputils.c 2003-02-09 14:18:23.000000000 +0100
+++ sscep-ng2/sceputils.c 2006-04-25 16:27:03.000000000 +0200
@@ -156,7 +156,8 @@
}
/* Copy the pointer and return */
- s->selfsigned = cert;
+ s->signercert = cert;
+ s->signerkey = rsa;
return (0);
}
diff -uN sscep/sscep.c sscep-ng2/sscep.c
--- sscep/sscep.c 2003-04-17 07:47:04.000000000 +0200
+++ sscep-ng2/sscep.c 2006-04-28 11:06:16.000000000 +0200
@@ -53,12 +53,15 @@
}
/* Skip first parameter and parse the rest of the command */
optind++;
- while ((c = getopt(argc, argv, "c:de:E:f:F:i:k:l:L:n:p:r:Rs:S:t:T:u:vw:")) != -1)
+ while ((c = getopt(argc, argv, "c:Cde:E:f:F:i:k:K:l:L:n:O:p:r:Rs:S:t:T:u:vw:")) != -1)
switch(c) {
case 'c':
c_flag = 1;
c_char = optarg;
break;
+ case 'C':
+ C_flag = 1;
+ break;
case 'd':
d_flag = 1;
break;
@@ -86,6 +89,10 @@
k_flag = 1;
k_char = optarg;
break;
+ case 'K':
+ K_flag = 1;
+ K_char = optarg;
+ break;
case 'l':
l_flag = 1;
l_char = optarg;
@@ -98,6 +105,10 @@
n_flag = 1;
n_num = atoi(optarg);
break;
+ case 'O':
+ O_flag = 1;
+ O_char = optarg;
+ break;
case 'p':
p_flag = 1;
p_char = optarg;
@@ -137,6 +148,7 @@
w_char = optarg;
break;
default:
+ printf("argv: %s\n", argv[optind]);
usage();
}
argc -= optind;
@@ -402,15 +414,38 @@
case SCEP_OPERATION_GETCERT:
case SCEP_OPERATION_GETCRL:
/* Read local certificate */
- read_local_cert();
+ if (!l_flag) {
+ fprintf(stderr, "%s: missing local cert (-l)\n", pname);
+ exit (SCEP_PKISTATUS_FILE);
+ }
+ read_cert(&localcert, l_char);
case SCEP_OPERATION_ENROLL:
/*
* Read in CA cert, private key and certificate
* request in global variables.
*/
- read_ca_cert();
- read_key();
+ read_ca_cert();
+
+ if (!k_flag) {
+ fprintf(stderr, "%s: missing private key (-k)\n", pname);
+ exit (SCEP_PKISTATUS_FILE);
+ }
+ read_key(&rsa, k_char);
+
+ if ((K_flag && !O_flag) || (!K_flag && O_flag)) {
+ fprintf(stderr, "%s: -O also requires -K (and vice-versa)\n", pname);
+ exit (SCEP_PKISTATUS_FILE);
+ }
+
+ if (K_flag) {
+ read_key(&renewal_key, K_char);
+ }
+
+ if (O_flag) {
+ read_cert(&renewal_cert, O_char);
+ }
+
if (operation_flag == SCEP_OPERATION_ENROLL)
read_request();
@@ -426,7 +461,14 @@
if (v_flag)
fprintf(stdout, "%s: generating selfsigned "
"certificate\n", pname);
- new_selfsigned(&scep_t);
+
+ if (! O_flag)
+ new_selfsigned(&scep_t);
+ else {
+ /* Use existing certificate */
+ scep_t.signercert = renewal_cert;
+ scep_t.signerkey = renewal_key;
+ }
/* Write the selfsigned certificate if requested */
if (L_flag) {
@@ -436,7 +478,7 @@
"file for writing\n", pname);
exit (SCEP_PKISTATUS_ERROR);
}
- if (PEM_write_X509(fp,scep_t.selfsigned) != 1) {
+ if (PEM_write_X509(fp,scep_t.signercert) != 1) {
fprintf(stderr, "%s: error while "
"writing certificate file\n", pname);
ERR_print_errors_fp(stderr);
@@ -643,7 +685,8 @@
void
usage() {
- fprintf(stdout, "\nsscep version %s\n\n" , VERSION);
+ fprintf(stdout, "\nsscep version %s using %s\n\n" ,
+ VERSION,SSLeay_version(SSLEAY_VERSION));
fprintf(stdout, "Usage: %s OPERATION [OPTIONS]\n"
"\nAvailable OPERATIONs are\n"
" getca Get CA/RA certificate(s)\n"
@@ -665,6 +708,8 @@
"\nOPTIONS for OPERATION enroll are\n"
" -k <file> Private key file\n"
" -r <file> Certificate request file\n"
+ " -K <file> Signature private key file, use with -O\n"
+ " -O <file> Signature certificate (used instead of self-signed)\n"
" -l <file> Write enrolled certificate in file\n"
" -e <file> Use different CA cert for encryption\n"
" -L <file> Write selfsigned certificate in file\n"
@@ -672,6 +717,8 @@
" -T <secs> Max polling time in seconds\n"
" -n <count> Max number of GetCertInitial requests\n"
" -R Resume interrupted enrollment\n"
+ " -C Check subject DN in the certificate return by the\n"
+ " CA (default is to match on the public key only)\n"
"\nOPTIONS for OPERATION getcert are\n"
" -k <file> Private key file\n"
" -l <file> Local certificate file\n"
diff -uN sscep/sscep.h sscep-ng2/sscep.h
--- sscep/sscep.h 2003-04-17 07:50:04.000000000 +0200
+++ sscep-ng2/sscep.h 2006-04-28 10:46:49.000000000 +0200
@@ -36,10 +36,9 @@
#include <openssl/objects.h>
#include <openssl/asn1_mac.h>
-
/* Global defines */
-#define VERSION "20030417"
+#define VERSION "20060428"
/* SCEP operations */
int operation_flag;
@@ -128,13 +127,13 @@
X509 *encert;
X509 *localcert;
X509 *othercert;
+X509 *renewal_cert;
X509_REQ *request;
EVP_PKEY *rsa;
+EVP_PKEY *renewal_key;
X509_CRL *crl;
FILE *cafile;
FILE *reqfile;
-FILE *keyfile;
-FILE *localfile;
FILE *otherfile;
FILE *crlfile;
@@ -207,7 +206,9 @@
int recipient_nonce_len;
/* Certificates */
- X509 *selfsigned;
+ X509 *signercert;
+ EVP_PKEY *signerkey;
+
EVP_PKEY *pkey;
/* Request */
@@ -251,13 +252,13 @@
int init_scep(void);
/* Read RSA private key file */
-void read_key(void);
+void read_key(EVP_PKEY** key, char* filename);
/* Read CA certificate file */
void read_ca_cert(void);
/* Read local certificate file */
-void read_local_cert(void);
+void read_cert(X509** cert, char* filename);
/* Read certificate request and private key */
void read_request(void);