1 This patch adds support for signing requests with an existing key.
2 It was taken from CertNanny <http://www.cynops.de/oss/CertNanny/>
4 diff -uN sscep/Makefile sscep-ng2/Makefile
5 --- sscep/Makefile 2003-01-22 06:23:18.000000000 +0100
6 +++ sscep-ng2/Makefile 2006-04-25 19:38:49.000000000 +0200
15 OBJS = sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o
18 - $(CC) $(CFLAGS) -lcrypto -o $(PROG) $(OBJS)
19 + $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o $(PROG) $(OBJS) $(LDLIBS)
22 rm -f $(PROG) $(OBJS) $(MAN) core
23 diff -uN sscep/README sscep-ng2/README
24 --- sscep/README 2003-04-17 07:49:46.000000000 +0200
25 +++ sscep-ng2/README 2006-04-28 10:27:44.000000000 +0200
27 o iPlanet CMS (getca and enroll works)*
28 o VeriSign Onsite (getca and enroll works)**
29 o Entrust VPN Connect (getca and enroll works)***
30 +o OpenCA (getca, enroll, getcrl and automatic approval works)****
32 (*) by default, subjectAltName extensions are dropped from certificate
33 (**) only DNS subjectAltName allowed (demo mode)
34 (***) demo requires to use /C=US/O=Entrust
36 +(****) automatic approval according to newer SCEP drafts requires
37 + OpenCA 0.9.2.4 or higher
45 -sscep version 20030131
46 +sscep version 2005XXXX
48 Usage: ./sscep OPERATION [OPTIONS]
51 OPTIONS for OPERATION enroll are
52 -k <file> Private key file
53 -r <file> Certificate request file
54 + -K <file> Signature private key file
55 + -O <file> Signature certificate (used instead of self-signed)
56 -l <file> Write enrolled certificate in file
57 -e <file> Use different CA cert for encryption
58 -L <file> Write selfsigned certificate in file
60 CAIdentifier Some CAs require you to define this. Example: mydomain.com
61 Command line option: -i
64 + Check subject DN in the certificate return by the CA. The
65 + default is to match on the public key only. Up to version
66 + 20040325 sscep checked on the subject DN only, which is a
67 + problem e.g. if the CA adds a SER attribute, enforces a
68 + naming policy or fixes encoding errors (e.g. with Java keytool
71 + Command line option: -C
73 CertReqFile Certificate request file created with mkrequest.
75 Command line option: -r
77 the signature. Example: ./enc.crt
78 Command line option: -e
80 +SignCertFile Instead of creating a self-signed certificate from the
81 + new key pair use an already existing certficate/key to
82 + sign the SCEP request. If the "old" certificate and
83 + key is used, the CA can verify that the holder of the
84 + private key for an existing certificate re-enrolls for
85 + a renewal certificate, allowing for automatic approval
86 + of the request. Requires specification of the corresponding
87 + signature private key file (-K, SignKeyFile).
89 + Command line option: -O
91 +SignKeyFile See SignCertFile. Specifies the corresponding private key.
93 + Command line option: -K
95 FingerPrint Display fingerprint algorithm. Available algorithms are md5
96 and sha1. Default is md5.
97 Command line option: -F
99 the challenge password), it returns SUCCESS as a first reply. Otherwise, the
100 enrollment requires manual signing and authentication (perhaps a phone call).
102 +Newer SCEP draft versions allow to use the existing certificate (issued
103 +by the CA) to authenticate a renewal request. In this context, the SCEP
104 +request with the new public key is signed with the old certificate and
105 +key (instead of using a self-signed certificate created from the new
107 +To use this feature, use the command line options -O and -K to specify
108 +the old certificate and private key (SignCertFile and SignCertKey
109 +in the configuration file).
110 +The actual behaviour of the SCEP server depends on the CA policy and
111 +on the capabilities of the SCEP server (not all servers implement
112 +this feature, using the existing certificate with an older SCEP server
113 +may or may not work, depending on implementation).
115 +Note: Newer versions of OpenCA (http://www.openca.info/) support
116 +an SCEP server that is capable of automatically approving SCEP requests
117 +signed with the already existing key pair.
120 STEP 5 - Use certificate
121 ========================
122 diff -uN sscep/cmd.h sscep-ng2/cmd.h
123 --- sscep/cmd.h 2003-01-30 08:57:34.000000000 +0100
124 +++ sscep-ng2/cmd.h 2006-04-28 10:01:10.000000000 +0200
129 +/* Check subject DN */
139 +/* Private key of already existing certificate */
147 +/* Already existing certificate (to be renewed) */
154 diff -uN sscep/draft-nourse-scep-11.txt sscep-ng2/draft-nourse-scep-11.txt
155 --- sscep/draft-nourse-scep-11.txt 1970-01-01 01:00:00.000000000 +0100
156 +++ sscep-ng2/draft-nourse-scep-11.txt 2006-04-25 16:27:03.000000000 +0200
159 +INTERNET DRAFT Xiaoyi Liu
160 +draft-nourse-scep-11.txt Cheryl Madson
161 +expires 11 Aug 2005 David McGrew
162 +(revised 11 Feb 2005) Andrew Nourse
165 +Category: Informational 11 Feb 2005
168 +Cisco Systems' Simple Certificate Enrollment Protocol(SCEP):
172 +This document is an Internet-Draft and is NOT offered in accordance
173 +with Section 10 of RFC2026, and the author does not provide the IETF
174 +with any rights other than to publish as an Internet-Draft
176 +Internet-Drafts are working documents of the Internet Engineering Task
177 +Force (IETF), its areas, and its working groups. Note that other
178 +groups may also distribute working documents as Internet-Drafts.
180 +Internet-Drafts are draft documents valid for a maximum of six months
181 +and may be updated, replaced, or obsoleted by other documents at any
182 +time. It is inappropriate to use Internet- Drafts as reference
183 +material or to cite them other than as "work in progress."
185 +The list of current Internet-Drafts can be accessed at
186 +http://www.ietf.org/ietf/1id-abstracts.txt
188 +The list of Internet-Draft Shadow Directories can be accessed at
189 +http://www.ietf.org/shadow.html.
191 +This memo provides information for the Internet community. This memo
192 +does not specify an Internet standard of any kind. Distribution of
193 +this memo is unlimited.
195 +By submitting this Internet-Draft, I certify that any applicable patent
196 +or other IPR claims of which I am aware have been disclosed, or will be
197 +disclosed, and any of which I become aware will be disclosed, in accordance
202 +This document specifies the Simple Certificate Enrollment Protocol,
203 +a PKI communication protocol which leverages existing technology by
204 +using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment
205 +protocol developed by Verisign, Inc. for Cisco Systems, Inc.
206 +It now enjoys wide support in both client and CA implementations.
211 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
212 + 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3
213 + 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3
214 + 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7
215 + 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10
216 + 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
217 + 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13
218 + 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14
219 + 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14
221 +
\fLiu/Madson/McGrew/Nourse [Page 2]
223 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
225 + 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15
226 + 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16
227 + 5.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . 16
228 + 5.2 Poll for Requester Initial Certificate . . . . . . . . . . 22
229 + 5.3 Certificate Access . . . . . . . . . . . . . . . . . . . . 26
230 + 5.4 CRL Access . . . . . . . . . . . . . . . . . . . . . . . 27
231 + 5.5 Get Certificate Authority Certificate . . . . . . . . . . 31
232 + 5.6 Get Certificate Authority Certificate Chain . . . . . . . 33
233 + 6. Security Considerations . . . . . . . . . . . . . . . . . 33
234 + 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33
235 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33
236 + Appendix A. Cisco Requester Subject Name Definition . . . . . . 34
237 + Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35
238 + Appendix C. Private OID Definitions . . . . . . . . . . . . . 36
239 + Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36
240 + Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37
241 + Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40
242 + Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41
243 + Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42
244 + Appendix Y. Author Contact Information. . . . . . . . . . . . . 43
245 + Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43
247 +Section 1. Introduction
249 +Public key technology is becoming more widely deployed and is becoming
250 +the basis for standards based security, such as the Internet Engineering
251 +Task Force's IPSEC and IKE protocols. With the use of public key
252 +certificates in network security protocols comes the need for a
253 +certificate management protocol that Public Key Infrastructure (PKI)
254 +clients and Certificate Authority servers can use to support certificate
255 +life cycle operations such as certificate enrollment and revocation, and
256 +certificate and CRL access.
258 +In the following, Section 2 gives an overview of the PKI operations,
259 +and Section 2.4 describes the security goals of the protocol and the
260 +mechanisms used to achieve them. The transport protocol and the
261 +security protocol PKCS#7 are described at Section 3 and Section 4,
262 +respectively. The last section, Section 5, specifies each PKI
263 +operation in terms of the message formats and the data structures of
266 +The appendices provide detailed specifications and examples. Requester
267 +subject names are specified in Appendix A, attribute OIDs are
268 +specified in Appendix C , and the SCEP state transitions are described
269 +in Appendix E. An example of a certificate enrollment request is
270 +provided in Appendix B, and an example LDAP query URL encoding is
271 +provided in Appendix D.
273 +The authors would like to thank Peter William of ValiCert, Inc.
274 +(formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and
275 +Christopher Welles of IRE, Inc. for their contributions to this protocol
276 +and to this document.
278 +
\fLiu/Madson/McGrew/Nourse [Page 3]
280 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
282 +2.0 The Goal of SCEP
283 +The goal of SCEP is to support the secure issuance of certificates to
284 +network devices in a scalable manner, using existing technology whenever
285 +possible. The protocol supports the following operations:
287 + CA and RA public key distribution
288 + Certificate enrollment
289 + Certificate revocation
293 +Certificate and CRL access can be achieved by using the LDAP protocol
294 +(as specified in Appendix D), or by using the query messages defined in
295 +SCEP. The use of HTTP certificate and CRL access, and the support of
296 +CDP as specified in RFC2459, will be specified in a future version of
297 +this document. In Section 2.1, we first define PKI entity types as well
298 +as the properties of each entity type. In Section 2.2, the PKI
299 +operations are described at functional level. Section 2.3 describes the
300 +transaction behavior of each PKI operations. The complete PKI messages
301 +are covered in Section 5.
303 +2.1 SCEP Entity types
305 +The entity types defined in SCEP are the "requester" type (i.e., IPSEC
306 +clients), the Certificate Authority (CA) entity type, and the
307 +Registration Authority entity type (RA). A requester is sometimes
308 +called a "SCEP client" in the following.
312 +A requester is an entity whose name is defined in a certificate
313 +subject name field and optionally, in SubjectAltName, a X.509
314 +certificate V3 extension. As a requester, a SCEP client is identified
315 +by a subject name consisting of the following naming attributes:
317 + Fully qualified domain name, for example, router.cisco.com
318 + IP address, Serial number, and/or x.500 distinguished name
320 +The fully qualified domain name is required for a requester that intends
321 +to use the certificate for ISAKMP. The IP address, serial number, and
322 +x.500 distinguished name are optional name attributes. In the
323 +certificate enrollment request, the PKCS#10 subject field contains the
324 +required and optional name attributes. The distinguished name, if any,
325 +should be the subject name field, while any domain name, serial number,
326 +or IP address supplied should be in the subjectAltName field. The
327 +subject name field may be empty (if there is no distinguished name)
328 +or the subjectAltName may be omitted, but not both.
330 +It is important to note that a client named as Alice.cisco.com is
331 +different than a client named as Alice.cisco.com plus the IP address
332 +name attribute 117.96.1.219. From CA point of view, the Distinguished
333 +names assigned in these two cases are distinct names.
336 +
\fLiu/Madson/McGrew/Nourse [Page 4]
338 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
340 +Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP
341 +address and User FQDN) must be presented in certificate's SubjectAltName
342 +extension. Multiple IPSEC entity names, (if any) are encoded as multiple
343 +values of a single SubjectAltName extension. The CA has the authority
344 +to assign a distinguished name to a requester, whether or not one was
345 +included in the request. The assigned DN should contain the SCEP client
346 +names as the relative DN.
348 +The attribute identifiers and an example of SCEP client subject name are
349 +specified in Appendix A. Appendix B has an example from Cisco VPN Client
352 +2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness
354 +A requester is required to generate asymmetric key pairs and to provide
355 +storage to store its private keys. If the requester does not have enough
356 +permanent memory to save its certificate, then it should be able to query
357 +its own certificate from the CA or an LDAP server, once the certificate
358 +has been issued. The public key pairs can be generated with a specific
359 +key usage. The key usage is conveyed to the CA through the certificate
360 +enrollment request. All current SCEP client implementations expect that
361 +there will be only one pair of keys for a given subject name
362 +and key usage combination and CA, at any time. This property is called
363 +the certificate-name uniqueness property, and it implies that a CA that
364 +implements SCEP will enforce the unique mapping between a SCEP client
365 +subject name and its key pairs with a given key usage. At any time, if
366 +the subject name is changed, or if the key is updated, the existing
367 +certificate would have to be revoked before a new one could be issued.
369 +It is desirable that the CA enforce certificate-name uniqueness, but
370 +it is not mandatory. However a CA that does not enforce uniqueness
371 +must provide some other mechanism to prevent the re-transmission of an
372 +enrollment request by a SCEP client from creating a second certificate
373 +or certificate request, nor can the second request merely be rejected.
374 +If a client times out from polling for a pending request it can
375 +resynchronize by reissuing the original request with the original
376 +subject name, key, and transaction ID. This should return the status of
377 +the original transaction, including the certificate if it was granted.
378 +It should not create a new transaction unless the original cert has been
379 +revoked, or the transaction arrives more than halfway through the
380 +validity time of the original certificate.
382 +An enrollment request that occurs more than halfway through the validity
383 +time of an existing certificate for the same subject name and key usage
384 +MAY be interpreted as a re-enrollment or renewal request and accepted.
385 +A new certificate with new validity dates may be issued, even though
386 +the old one is still valid, if the CA policy permits, as described in
387 +2.1.1.3. See also appendix G.
389 +2.1.1.2 Requester authentication
391 +As with every protocol that uses public-key cryptography, the
392 +association between the public keys used in the protocol and the
393 +identities with which they are associated must be authenticated in a
394 +
\fLiu/Madson/McGrew/Nourse [Page 5]
396 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
398 +cryptographically secure manner. This requirement is needed to
399 +prevent a "man in the middle" attack, in which an adversary that can
400 +manipulate the data as it travels between the protocol participants
401 +can subvert the security of the protocol. To satisfy this
402 +requirement, SCEP provides two authentication methods: manual
403 +authentication, and authentication based on pre-shared secret. In the
404 +manual mode, the requester is required to wait until its identity can
405 +be verified by the CA operator using any reliable out-of-band
406 +method. To prevent a "man-in-the-middle" attack, a SHA-1 or MD5
407 +`fingerprint' generated on the PKCS#10 (before PKCS #7 enveloping and
408 +signing) must be compared out-of-band between the server and the
409 +requester. SCEP clients and CAs (or RAs, if appropriate) must display
410 +this fingerprint to the operator to enable this verification if manual
411 +mode is used. Failing to provide this information leaves the protocol
412 +vulnerable to attack by sophisticated adversaries. When utilizing a
413 +pre-shared secret scheme, the server should distribute a shared secret
414 +to the requester which can uniquely associate the enrollment request
415 +with the given end entity. The distribution of the secret must be
416 +private: only the end entity should know this secret. The actual
417 +binding mechanism between the requester and the secret is subject to
418 +the server policy and implementation. When creating the enrollment
419 +request, the requester is asked to provide a challenge password. When
420 +using the pre-shared secret scheme, the requester must enter the
421 +re-distributed secret as the password. In the manual authentication
422 +case, the challenge password only used to authenticate a request for
423 +the certificate's revokation. This challenge password is included as
424 +a PKCS#10 attribute, and is sent to the server as encrypted data. The
425 +PKCS#7 envelope protects the privacy of the challenge password with
428 +2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates
430 +In this protocol, the communication between the requester and the
431 +certificate authority is secured by using PKCS#7 as the messaging
432 +protocol. PKCS#7, however, is a protocol which assumes the
433 +communicating entities already possess the peer's certificates and
434 +requires both parties use the issuer names and issuer assigned
435 +certificate serial numbers to identify the certificate in order to
436 +verify the signature and decrypt the message. If the requesting
437 +system already has a certificate issued by the CA, that certificate
438 +may be presented as credentials for the renewal of that certificate if
439 +the CA supports the "Renewal" capability and the CA policy permits the
440 +certificate to be renewed. If the requester has no certificate issued
441 +by the CA, or if the CA does not support and permit renewal, the
442 +requestor must generate a self-signed certificate with the requester
443 +subject name (the same name later used in the PKCS#10) as both issuer
444 +and subject name. During the certificate enrollment, the requester
445 +will first post itself as the signing authority by attaching the
446 +self-signed certificate to the signed certificate request. When the
447 +Certificate Authority makes the envelope on the issued certificate
448 +using the public key included in the self-signed certificate, it
449 +should use the same issuer name and serial number as conveyed in the
450 +self-signed certificate to inform the end entity on which private key
451 +should be used to open the envelope.
452 +
\fLiu/Madson/McGrew/Nourse [Page 6]
454 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
456 +Note that when a client enrolls for separate encryption and signature
457 +certificates, it may use the signature certificate to sign both
458 +requests, and then expect its signature key to be used to encrypt
459 +both responses. In any case, the recipientinfo on the envelope should
460 +reflect the key used to encrypt the request.
462 +2.1.1.4 Trusted CA Store
464 +To support interoperability between IPSEC peers whose certificates are
465 +issued by different CA, SCEP allows the users to configure multiple
466 +trusted certificates. Trusted certificates are have been configured as
467 +such in the client, based on some out-of-band means such as a "fingerprint".
468 +These trusted certificates are used to verify certificate chains that end
469 +in those certificates.
471 +2.1.2 Certificate Authority
473 +A Certificate Authority(CA) is an entity whose name is defined in the
474 +certificate issuer name field. Before any PKI operations can begin,
475 +the CA generates its own public key pair and creates a self-signed CA
476 +certificate, or causes another CA to issue a certificate to it.
477 +Associated with the CA certificate is a fingerprint which will be used
478 +by the requester to authenticate the received CA certificate if it is
479 +self-signed. The fingerprint is created by calculating a SHA-1 or MD5
480 +hash on the whole CA certificate. Before any requester can start its
481 +enrollment, this CA certificate has to be configured at the entity
482 +side securely. For IPSEC clients, the client certificates must have
483 +SubjectAltName extension. To utilize LDAP as a CRL query protocol,
484 +the certificates must have a CRL Distribution Point. Key usage is
485 +optional. Without key usage, the public key is assumed as a general
486 +purpose public key and it can be used for all the purposes.
488 +A Certificate Authority may enforce certain name policy. When using
489 +X.500 directory name as the subject name, all the name attributes
490 +specified in the PKCS#10 request should be included as Relative DN. All
491 +the name attributes as defined in RFC2459 should be specified in the
492 +SubjectAltName. An example is provided in Appendix A.
494 + If there is no LDAP query protocol support, the Certificate Authority
495 +should answer certificate and CRL queries, and to this end it should be
496 +online all the time.
498 +The updating of the CA's public key is addressed in Appendix G.
500 +2.1.3 Registration Authorities
502 +In an environment where an RA is present, a requester performs
503 +enrollment through the RA. In order to setup a secure channel with an RA
504 +using PKCS#7, the RA certificate(s) have to be obtained by the client
505 +in addition to the CA certificate(s).
507 +In the following, the CA and RA are specified as one entity in the
508 +context of PKI operation definitions.
509 +
\fLiu/Madson/McGrew/Nourse [Page 7]
510 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
511 +2.2 SCEP Operations Overview
513 +In this section, we give a high level overview of the PKI operations as
516 +2.2.1 Requester Initialization
518 +The requester initialization includes the key pair generation and the
519 +configuring of the required information to communicate with the
520 +certificate authority.
524 +Before a requester can start PKI transaction, it must have at least one
525 +asymmetric key pair, using the selected algorithm (the RSA algorithm is
526 +required in SCEP, and is the only algorithm in current implementations).
528 +Key pairs may be intended for particular purposes, such as encryption only,
529 +or signing only. The usage of any associated certificate can be restricted
530 +by adding key usage and extended key usage attributes to the PKCS#10.
532 +2.2.1.2 Required Information
534 +A requester is required to have the following information configured
535 +before starting any PKI operations:
537 +1. the certificate authority IP address or fully-qualified domain name,
538 +2. the certificate authority HTTP CGI script path, and
539 + the HTTP proxy information in case there is no direct Internet
540 + connection to the server,
541 +3. If CRLs are being published by the CA to an LDAP directory server,
542 + and there is a CRL Distribution Point containing only an X.500 directory
543 + name, then the client will need to know the LDAP server fully-qualified
544 + domain name or IP address. CRL Distribution Points are discussed in
545 + more detail in RFC 2459.
548 +2.2.2 CA/RA Certificate Distribution
550 +Before any PKI operation can be started, the requester needs to get
551 +the CA/RA certificates. At this time, since no public key has been
553 +
\fLiu/Madson/McGrew/Nourse [Page 8]
555 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
557 +exchanged between the requester and the CA/RA, the message to get the
558 +CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the
559 +CA/RA certificate distribution is implemented as a clear HTTP Get
560 +operation. After the requester gets the CA certificate, it has to
561 +authenticate the CA certificate by comparing the finger print with the
562 +CA/RA operator. Since the RA certificates are signed by the CA, there is
563 +no need to authenticate the RA certificates.
565 +This operation is defined as a transaction consisting of one HTTP Get
566 +message and one HTTP Response message:
568 + REQUESTER CA SERVER
569 + Get CA/RA Cert: HTTP Get message
570 + ----------------------------->
571 + CA/RA Cert download: HTTP Response message
572 + <---------------------------------------
573 + Compute finger print and
575 + Receive call and check finger print
577 +If an RA is in use, a degenerated PKCS#7 with a certificate chain
578 +consisting of both RA and CA certificates is sent back to the end
579 +entity. Otherwise the CA certificate is directly sent back as the
580 +HTTP response payload.
583 +2.2.3 Certificate Enrollment
585 +A requester starts an enrollment transaction by creating a certificate
586 +request using PKCS#10 and sends it to the CA/RA enveloped using the
587 +PKCS#7. After the CA/RA receives the request, it will either
588 +automatically approve the request and send the certificate back, or it
589 +will require the requester to wait until the operator can manually
590 +authenticate the identity of the requester. Two attributes are
591 +included in the PKCS#10 certificate request - a Challenge Password
592 +attribute and an optional ExtensionReq attribute which will be a
593 +sequence of extensions the requester would like to be included in its
594 +V3 certificate extensions. The Challenge Password may be used to
595 +authenticate either the enrollment request itself, or a verbal
596 +revocation request for the issued certificate in the event of key
597 +compromise or other reason.
599 +In the automatic mode, the transaction consists of one PKCSReq PKI
600 +Message, and one CertRep PKI message. In the manual mode, the requester
601 +enters into polling mode by periodically sending a GetCertInitial PKI
602 +message to the server, until the server operator completes the manual
603 +authentication, after which the CA will respond to GetCertInitial by
604 +returning the issued certificate. A CA MAY run in automatic mode for
605 +preapproved requests, and manual mode for the rest. A request with a
606 +non-null password is not necessarily a pre-approved request. It is up
607 +to the CA server to decide. Polling mode is entered whenever the
608 +server returns a PENDING response.
610 +
\fLiu/Madson/McGrew/Nourse [Page 9]
611 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
614 +The transaction in automatic mode:
616 + REQUESTER CA SERVER
618 +PKCSReq: PKI cert. enrollment msg
619 + --------------------------------> CertRep: pkiStatus = SUCCESS
620 + certificate attached
621 + <------------------------------
622 + Receive issued certificate.
624 +The transaction in manual mode:
626 + REQUESTER CA SERVER
627 + PKCSReq: PKI cert. enrollment msg
628 + --------------------------------> CertRep: pkiStatus = PENDING
629 + <------------------------------
630 + GetCertInitial: polling msg
631 + --------------------------------> CertRep: pkiStatus = PENDING
632 + <------------------------------
633 + ................. <manual identity authentication................
635 + GetCertInitial: polling msg
636 + --------------------------------> CertRep: pkiStatus = SUCCESS
637 + certificate attached
638 + <------------------------------
639 + Receive issued certificate.
641 +2.2.4 Requester Certificate Revocation
643 +A requester should be able to revoke its own certificate. Currently
644 +the revocation is implemented as a manual process. In order to revoke a
645 +certificate, the requester makes a phone call to the CA server
646 +operator. The operator will come back asking the ChallengePassword
647 +(which has been sent to the server as an attribute of the PKCS#10
648 +certificate request). If the ChallengePassword matches, the certificate
649 +is revoked. The reason of the revocation is documented by CA/RA.
651 +2.2.5 Certificate Access
653 +There are two methods to query certificates. The first method is to use
654 +LDAP as a query protocol. Using LDAP to query assumes the client
655 +understand the LDAP scheme supported by the CA. The SCEP client assumes
656 +that the subject DN name in the certificate is used as the URL to query the
657 +certificate. The standard attributes (userCertificate and caCertificate)
660 +For the environment where LDAP is not available, a certificate query
661 +message is defined to retrieve the certificates from the CA.
663 +To query a certificate from the certificate authority, a requester
664 +sends a request consisting of the certificate's issuer name and the
665 +serial number. This assumes that the requester has saved the issuer
667 +
\fLiu/Madson/McGrew/Nourse [Page 10]
669 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
671 +name and the serial number of the issued certificate from the previous
672 +enrollment transaction. The transaction to query a certificate consists
673 +of one GetCert PKI message and one CertRep PKI message:
675 + REQUESTER CA SERVER
676 + GetCert: PKI cert query msg
677 + -------------------------------> CertRep: pkiStatus = SUCCESS
680 + <-----------------------------
681 + Receive the certificate.
683 +2.2.6 CRL Distribution
685 +The CA/RA will not "push" the CRL to the end entities. The query of the
686 +CRL can only be initialized by the requester.
688 +There are three methods to query CRL.
690 +The CRL may be retrieved by a simple HTTP GET. If the CA supports this
691 +method, it should encode the URL into a CRL Distribution Point extension
692 +in the certificates it issues. Support for this method should be
693 +incorporated in new and updated clients, but may not be in older
696 +The second method is to query CRL using LDAP. This assumes the CA server
697 +supports CRL LDAP publishing and issues the CRL Distribution Point in
698 +the certificate. The CRL Distribution Point is encoded as a DN. Please
699 +refer to Appendix D for the examples of CRL Distribution Point.
701 +The third method is implemented for the CA which does not support LDAP
702 +CRL publishing or does not implement the CRL Distribution Point. In this
703 +case, a CRL query is composed by creating a message consists of the CA
704 +issuer name and the CA's certificate serial number. This method is
705 +deprecated because it does not scale well and requires the CA to be a
706 +high-availability service.
708 +The message is sent to the CA in the same way as the other SCEP
709 +requests: The transaction to query CRL consists of one GetCRL PKI
710 +message and one CertRep PKI message which have no certificates but CRL.
712 + REQUESTER CA SERVER
713 + GetCRL: PKI CRL query msg
714 + ----------------------------------> CertRep: CRL attached
715 + <--------------------------------
717 +2.3 PKI Operation Transactional Behavior
719 +As described before, a PKI operation is a transaction consisting of the
720 +messages exchanged between a requester and the CA/RA. This section
721 +will specify the transaction behavior on both the requester and the
724 +
\fLiu/Madson/McGrew/Nourse [Page 11]
726 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
728 +certificate authority server. Because the protocol is basically a two
729 +way communication protocol without a confirmation message from the
730 +initiating side, state and state resynchronization rules have to be
731 +defined, in case any error happens at either side. Before the state
732 +transition can be defined, the notion of transaction identifier has to
735 +2.3.1 Transaction Identifier
737 +A transaction identifier is a string generated by the entity when
738 +starting a transaction. Since all the PKI operations defined in this
739 +protocol are initiated by the requester, it is the responsibility of
740 +the requester to generate a unique string as the transaction
741 +identifier. All the PKI messages exchanged for a given PKI transaction
742 +must carry the same transaction identifier. The transaction identifier
743 +is generated as a SHA-1 or MD5 hash on the public key value for which the
744 +enrollment request is made. This allows the SCEP client to reuse the
745 +same transaction identifier if it is reissuing a request for the same
746 +certificate (i.e. a certificate with the same subject, issuer, and key).
747 +The SCEP protocol requires that transaction identifiers be unique, so
748 +that queries can be matched up with transactions. For this reason, in
749 +those cases in which separate signing and encryption certificates are
750 +issued to the same requester, the keys must be different.
752 +2.3.2 State Transitions in Certificate Enrollment
754 +The requester state transitions during enrollment operation are
755 +indicated in the diagram below:
758 + GetCertInitial triggered by timeout or
759 + | | manual authentication
761 + [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED]
762 + | PKCSReq | CertRep with SUCCESS
765 + +--------<-------------------+
766 + request rejected, timeout, or error
768 +As described in the section 2.2.3, certificate enrollment starts at the
769 +state CERT-NONEXISTANT. Sending PKCSReq changes the state to
770 +CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the
771 +state to CERT-ISSUED. In the case the server sending back the response
772 +with pending status, the requester will keep polling certificate
773 +response by sending GetCertInitial to the server, until either a CertRep
774 +with SUCCESS status is received, or the maximum polling number has been
777 +If an error or timeout occurs in the CERT-REQ-PENDING state, the end
778 +entity will transition to the CERT-NONEXISTANT state.
781 +
\fLiu/Madson/McGrew/Nourse [Page 12]
783 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
786 +The client administrator will, eventually, start up another enrollment
787 +request. It is important to note that, as long as the requester does
788 +not change its subject name or keys, the same transaction id will be
789 +used in the "new" transaction. This is important because based on this
790 +transaction id, the certificate authority server can recognize this as
791 +an existing transaction instead of a new one.
794 +2.3.3 Transaction Behavior of Certificate/CRL Access
796 +There is no state maintained during certificate access and CRL access
797 +transaction. When using the certificate query and CRL query messages
798 +defined in this protocol, the transaction identifier is still required
799 +so that the requester can match the response message with the
800 +upstanding request message. When using LDAP to query the certificate and
801 +the CRL, the behavior is specified by the LDAP protocol.
805 +The security goals of SCEP are that no adversary can:
807 +o subvert the public key/identity binding from that intended,
808 +o discover the identity information in the enrollment requests and
809 + issued certificates,
810 +o cause the revocation of certificates with any non-negligible
813 +Here an adversary is any entity other than the requester and the CA
814 +(and optionally the RA) participating in the protocol that is
815 +computationally limited, but that can manipulate data during
816 +transmission (that is, a man-in-the-middle). The precise meaning of
817 +'computationally limited' depends on the implementer's choice of
818 +cryptographic hash functions and ciphers. The required algorithms are
819 +RSA, DES, and either SHA-1 or MD5, depending on the "SHA-1" CA Capability.
822 +The first and second goals are met through the use of PKCS#7 and PKCS#10
823 +encryption and digital signatures using authenticated public keys. The
824 +CA's public key is authenticated via the checking of the CA fingerprint,
825 +as specified in Section 2.1.2, and the SCEP client's public key is
826 +authenticated through the manual authentication or pre-shared secret
827 +authentication, as specified in Section 2.1.1.2. The third goal is met
828 +through the use of a Challenge Password for revocation, that is chosen
829 +by the SCEP client and communicated to the CA protected by the PKCS#7
830 +encryption, as specified in Section 2.2.4.
832 +The motivation of the first security goal is straightforward. The
833 +motivation for the second security goal is to protect the identity
834 +information in the enrollment requests and certificates. For example,
835 +two IPSEC hosts behind a firewall may need to exchange certificates, and
836 +may need to enroll certificates with a CA that is outside of a firewall.
837 +Most networks with firewalls seek to prevent IP addresses and DNS
839 +
\fLiu/Madson/McGrew/Nourse [Page 13]
841 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
843 +information from the trusted network leaving that network. The second
844 +goal enables the hosts in this example to enroll with a CA outside the
845 +firewall without revealing this information. The motivation for the
846 +third security goal is to protect the SCEP clients from denial of
849 +Section 3 Transport Protocol
851 +In the SCEP protocol, HTTP is used as the transport protocol for the PKI
854 +3.1 HTTP "GET" and "POST" Message Format
856 +The following is the syntax definition of a HTTP GET message sent from
857 +a requester to a certificate authority server:
859 +Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE
861 + CGI-PATH defines the actual CGI path to invoke the CGI program which
862 + parses the request.
863 + CGI-PROG is set to be the string "pkiclient.exe". This is intended
864 + to be the program that the CA will use to handle the SCEP transactions,
865 + though the CA may ignore CGI-PROG and use only the CGI-PATH.
866 + OPERATION is set to be the string "PKIOperation" when the GET message
867 + carries a PKI message to request certificates or CRL; OPERATION is set
868 + to be the string "GetCACaps", "GetCACert", "GetNextCACert" or
869 + "GetCACertChain" when the GET operation is used to get CA capabilities,
870 + CA/RA certificate, the replacement CA/RA certificates for when the
871 + current ones expire, or the CA Cert chain (respectively).
873 + When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI message,
874 + When OPERATION is GetCACert, MESSAGE is a CRL distribution
875 + point in URI format, otherwise, MESSAGE is a string which represents
876 + the certificate authority issuer identifier.
878 +SCEP uses the HTTP "GET" and "POST" messages to request information from the CA.
879 +Requests for CA certificates or capabilities are sent in the clear, using "GET",
880 +with the OPERATION and MESSAGE fields identifying the requested data.
881 +CRLs may also be requested in the clear if the CA supports it.
883 +Other types of requests are sent using the PKCS#7 secure protocol.
884 +These may be issued by means of a GET operation with
885 +OPERATION and MESSAGE parameters in the Request-URL. OPERATION
886 +identifies the type of GET operation, and MESSAGE is actually the PKCS#7
887 +message Base64-Encoded.
889 +For example. a requester may submit a message via HTTP to the server
892 +GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
893 +QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA==
894 +
\fLiu/Madson/McGrew/Nourse [Page 13a]
896 +If supported by the CA, the message may also be sent via HTTP POST:
898 +POST /cgi-bin/pkiclient.exe?operation=PKIOperation
900 +This is further described in Appendix H.
901 +To determine if the CA supports POST, use the GetCACaps message described
905 +3.2 Response Message Format
907 +For each GET operation, the CA/RA server will return a MIME object via
908 +HTTP. For a GET operation with PKIOperation as its type, the response is
909 +tagged as having a Content Type of application/x-pki-message. The body
910 +of this message is a BER encoded binary PKI message. The following is an
911 +example of the response:
913 +"Content-Type:application/x-pki-message\n\n"<BER-encoded PKI msg>
915 +In the case of GET operation with a type of GetCACert the MIME content
916 +type returned will depend on whether or not an RA is in use. If there
917 +is no RA, only the CA certificate is sent back in the response, and
918 +the response has the content type tagged as
919 +application/x-x509-ca-cert. the body of the response is a DER encoded
920 +binary X.509 certificate. For example:
922 +"Content-Type:application/x-x509-ca-cert\n\n"<BER-encoded X509>
924 +If there is an RA, the RA certificates are sent back together with the
925 +CA certificates, a certificate-only PKCS#7 SignedData is sent back in
926 +the response where the SignerInfo is empty. Section 5 has the detailed
927 +definition of the message format in this case. The content type is
928 +application/x-x509-ca-ra-cert.
930 +The response to GetNextCACert is always a certificates-only PKCS#7
931 +SignedData with a content type of application/x-x509-ca-ra-cert.
932 +If there is an RA, The signer is the current RA certificate. Otherwise,
933 +the signer is the current CA certificate.
935 +If the CA supports it, PKIOperation may also be done via an HTTP POST.
936 +This is described in Appendix H.
938 +
\fLiu/Madson/McGrew/Nourse [Page 14]
940 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
942 +Section 4 Secure Transportation: PKCS#7
944 +PKCS#7 is a general enveloping mechanism that enables both signed and
945 +encrypted transmission of arbitrary data. It is widely implemented and
946 +included in the RSA tool kit. In this section, the general PKCS#7
947 +enveloped PKI message format is specified. The complete PKCS#7 message
948 +format for each PKI transaction will be covered in Section 5.
950 +4.1 SCEP Message Format
952 +As a transaction message, a SCEP message has a set of transaction
953 +specific attributes and an information portion. Employing PKCS#7
954 +protocol, the transaction specific attributes are encoded as a set of
955 +authenticated attributes of the SignedData. The information portion will
956 +first be encrypted to become Enveloped Data, and then the digest of the
957 +enveloped information portion is included as one of the message digest
958 +attributes and being signed together with the other transaction specific
961 +By applying both enveloping and signing transformations, a SCEP message
962 +is protected both for the integrity of its end-end-transition
963 +information and the confidentiality of its information portion. The
964 +advantage of this technique over the conventional transaction message
965 +format is that, the signed transaction type information and the status
966 +of the transaction can be determined prior to invoke security handling
967 +procedures specific to the information portion being processed.
969 +The following is an example of a SCEP message with its enveloped and
970 +signed data portion represented by pkcsPKISigned and
971 +pkcsPKIEnveloped. The out-most of any PKI message is a blob of
972 +ContentInfo, with its content type set to SignedData and the actual
973 +signed data as the content.
975 +
\fLiu/Madson/McGrew/Nourse [Page 15]
977 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
979 + pkiMessage ContentInfo ::= {
980 + contentType {pkcs-7 signedData(2)}
981 + content pkcsPKISigned
983 + pkcsPKISigned SignedData ::= {
985 + digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549)
986 + digestAlgorithm(2) 5}
988 + contentType {pkcs-7 1} -- data content identifier
989 + content pkcsPKIEnvelope -- enveloped information portion
991 + certificates -- signer certificate chain
992 + signerInfo -- including signed transaction info and the digest
993 + -- of the enveloped information portion as the
994 + -- authenticated attributes
996 + pkcsPKIEnveloped EnvelopedData ::= {
998 + recipientInfos -- information required to open the envelop
999 + encryptedContentInfo {
1000 + contentType {pkcs-7 1} -- data content identifier
1001 + contentEncryptionAlgorithm
1002 + encryptedContent -- encrypted information portion
1006 +4.2 Signed Transaction Attributes
1008 +The following transaction attributes are encoded as authenticated
1009 +attributes. Please refer to Appendix B for the OID definitions.
1011 +transactionID PrintableString -- Decimal value as a string
1012 + messageType PrintableString -- Decimal value as a string
1013 + pkiStatus PrintableString -- Decimal value as a string
1014 + failinfo PrintableString -- Decimal value as a string
1015 + senderNonce Octet String
1016 + recipientNonce Octet String
1020 + The transactionID is an attribute which uniquely identify a
1021 + transaction. This attribute is required in all PKI messages.
1023 + The messageType attribute specify the type of operation performed by the
1024 + transaction. This attribute is required in all PKI
1025 + messages. Currently, the following message types are defined:
1027 + PKCSReq (19) -- Permits use of PKCS#10 certificate request
1028 + CertRep (3) -- Response to certificate or CRL request
1029 + GetCertInitial (20) -- Certificate polling in manual enrollment
1030 + GetCert (21) -- Retrieve a certificate
1031 + GetCRL (22) -- Retrieve a CRL
1033 +
\fLiu/Madson/McGrew/Nourse [Page 16]
1035 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1038 + All response message will include transaction status information which
1039 + is defined as pkiStatus attribute:
1041 + SUCCESS (0) -- request granted
1042 + FAILURE (2) -- request rejected
1043 + PENDING (3) -- request pending for manual approval.
1045 + If the status in the response is FAILURE, the failinfo attribute will
1046 + contain one of the following failure reasons:
1048 + badAlg (0) -- Unrecognized or unsupported algorithm ident
1049 + badMessageCheck (1) -- integrity check failed
1050 + badRequest (2) -- transaction not permitted or supported
1051 + badTime (3) -- Message time field was not sufficiently close
1052 + to the system time
1053 + badCertId (4) -- No certificate could be identified matching
1054 + the provided criteria
1056 + The attributes of senderNonce and recipientNonce are the 16 byte
1057 + random numbers generated for each transaction to prevent the replay
1060 +When a requester sends a PKI message to the server, a senderNonce is
1061 +included in the message. After the server processes the request, it will
1062 +send back the requester senderNonce as the recipientNonce and generates
1063 +another nonce as the senderNonce in the response message. Because the
1064 +proposed pki protocol is a two-way communication protocol, it is clear
1065 +that the nonce can only be used by the requester to prevent the
1066 +replay. The server has to employ extra state related information to
1067 +prevent a replay attack.
1069 +Section 5. SCEP Transaction Specification
1071 +In this section each SCEP transaction is specified in terms of the
1072 +complete messages exchanged during the transaction.
1074 +5.1 Certificate Enrollment
1076 +The certificate enrollment transaction consists of one PKCSReq message
1077 +sent to the certificate authority from a requester, and one CertRep
1078 +message sent back from the server. The pkiStatus returned in the
1079 +response message is either SUCCESS, or FAILURE, or PENDING. The
1080 +information portion of a PKCSReq message is a PKCS#10 certificate
1081 +request, which contains the subject Distinguished Name, the subject
1082 +public key, and two attributes, a ChallengePassword attribute to be used
1083 +for revocation, and an optional ExtensionReq attribute which will be a
1084 +sequence of extensions the requester expects to be included in its V3
1085 +certificate extensions. One of the extension attribute specifies the key
1086 +usage. If the request is granted, the pkiStatus is set to SUCCESS, and
1087 +the certificate is returned in CertRep; if the request is rejected, the
1090 +
\fLiu/Madson/McGrew/Nourse [Page 17]
1092 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1094 +pkiStatus is set to FAILURE; if the server requires manual approval of
1095 +the request, the pkiStatus is set to PENDING. The messages exchanged
1096 +in the manual authentication mode is further specified in Section 5.2.
1099 + Both the requester and the certificate authority have completed their
1100 + initialization process. The requester has already been configured
1101 + with the CA/RA certificate.
1104 + Either the certificate is received by the requester, or the end
1105 + entity is notified to do the manual authentication, or the request
1108 +5.1.1 PKCSReq Message Format
1110 +A PKCSReq message is created by following the steps defined below:
1112 +1. Create a PKCS#10 certificate request which is signed by the end
1113 + entity's private key, corresponding to the public key included in
1114 + the PKCS#10 certificate request. This constitutes the information
1115 + portion of PKCSReq.
1117 +2. Encrypt the PKCS#10 certificate request using a randomly generated
1118 + content-encryption key. This content-encryption key is then
1119 + encrypted by the CA's* public key and included in the recipientInfo.
1120 + This step completes the "envelope" for the PKCS#10 certificate
1123 +3. Generate a unique string as the transaction id.
1125 +4. Generate a 16 byte random number as senderNonce.
1127 +5. Generate message digest on the enveloped PKCS#10 certificate request
1128 + using the selected digest algorithm.
1130 +6. Create SignedData by adding the requester's self- or CA-certificate
1131 + as the signer's public key certificate. Include the message type,
1132 + transaction id, the senderNonce and the message digest as the
1133 + authenticated attributes and sign the attributes using the end
1134 + entity's private key. This completes the SignedData.
1136 +7. The SignedData is prepended with the ContenInfo blob which indicates
1137 + a SignedData object. This final step completes the create of a
1138 + complete PKCSReq PKI message.
1140 +In the following, the PKCSReq message is defined following the ASN.1
1143 +For readability, the values of a field is either represented by a quoted
1144 +string which specifies the intended value, or a constant when the value
1148 +
\fLiu/Madson/McGrew/Nourse [Page 18]
1150 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1152 + -- PKCSReq information portion
1153 + pkcsCertReq CertificationRequest ::= { -- PKCS#10
1155 + subject "the requester's subject name"
1156 + subjectPublicKeyInfo {
1157 + algorithm {pkcs-1 1} -- rsa encryption
1158 + subjectPublicKey "DER encoding of the requester's public key"
1161 + challengePassword {{pkcs-9 7} "password string" }
1164 + signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption
1165 + signature "bit string which is created by signing inner content
1166 + of the defined pkcsCertReq using requester's private
1167 + key, corresponding to the public key included in
1168 + subjectPublicKeyInfo."
1170 + -- Enveloped information portion
1171 + pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7
1175 + issuerAndSerialNumber {
1176 + issuer "the CA issuer name"
1177 + serialNumber "the CA certificate serial number"
1179 + keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption
1180 + encryptedKey "content-encryption key
1181 + encrypted by CA public key"
1183 + encryptedContentInfo {
1184 + contentType {pkcs-7 1} -- data content
1185 + contentEncryptionAlgorithm "object identifier
1186 + for DES encryption"
1187 + encryptedContent "encrypted pkcsCertReq using the content-
1192 + pkcsCertReqSigned SignedData ::= { -- PKCS#7
1194 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1195 + digestAlgorithm(2) 5}
1197 + contentType {pkcs-7 1} -- data content identifier
1198 + content pkcsCertReqEnvelope
1200 + certificate { -- requester self-signed or CA-issued certificate
1202 + serialNumber "the transaction id associated with enrollment"
1203 + signature {pkcs-1 4} -- md5WithRSAEncryption
1206 +
\fLiu/Madson/McGrew/Nourse [Page 19]
1208 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1210 + issuer " the requester's subject name"
1212 + notBefore "a UTC time"
1213 + notAfter "a UTC time"
1215 + subject "the requester's subject name"
1216 + subjectPublicKeyInfo {
1217 + algorithm {pkcs-1 1}
1218 + subjectPublicKey "DER encoding of requester's public key"
1220 + signatureAlgorithm {pkcs-1 4}
1221 + signature "the signature generated by using the requester's
1222 + private key corresponding to the public key in
1223 + this certificate."
1227 + issuerAndSerialNumber {
1228 + issuer "the requester's subject name"
1229 + serialNumber "the transaction id associated
1230 + with the enrollment"
1232 + digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549)
1233 + digestAlgorithm(2) 5}
1234 + authenticateAttributes {
1235 + contentType {{pkcs-9 3} {pkcs-7 1}}
1236 + messageDigest {{pkcs-9 4} "an octet string"}
1237 + transaction-id {{id-attributes transId(7)} "printable
1239 + -- this transaction id will be used
1240 + -- together with the subject name as
1241 + -- the identifier of the requester's key
1242 + -- pair during enrollment
1243 + messageType {{id-attributes messageType(2)} "PKCSReq"}
1244 + senderNonce {{id-attributes senderNonce(5)}
1245 + "a random number encoded as a string"}
1247 + digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption
1248 + encryptedDigest "encrypted digest of the authenticated
1249 + attributes using requester's private key"
1252 + pkcsReq PKIMessage ::= {
1253 + contentType {pkcs-7 2}
1254 + content pkcsCertRepSigned
1264 +
\fLiu/Madson/McGrew/Nourse [Page 20]
1266 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1268 +5.1.2 CertRep Message Format
1270 +The response to an SCEP enrollment request is a CertRep message.
1272 +5.1.2.1 PENDING Response
1274 +When the CA is configured to manually authenticate the requester,
1275 +the CertRep is returned with the attribute pkiStatus set to PENDING.
1276 +The data portion for this message is null. Only the transaction
1277 +required attributes are sent back.
1279 +CertRepSigned SignedData ::= { -- PKCS#7
1281 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1282 + digestAlgorithm(2) 5}
1283 + contentInfo {contentType {pkcs-7 1} -- empty content
1287 + issuerAndSerialNumber {
1288 + issuer "name of CA that issued the CA [RA] cert"
1289 + serialNumber "the serial number of the CA [RA] cert"
1291 + digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549)
1292 + digestAlgorithm(2) 5}
1293 + authenticateAttributes {
1294 + contentType {{pkcs-9 3} {pkcs-7 1}}
1295 + messageDigest {{pkcs-9 4} NULL}
1296 + messageType {{id-attribute messageType(0)} "CertRep"}
1297 + transaction-id {{id-attributes transid(7)} "printablestring"}
1298 + --- same transaction id used in PKCSReq
1299 + pkiStatus {{id-attributes pkiStatus(3)} "PENDING"}
1300 + recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>}
1301 + senderNonce {{id-attributes senderNonce(5)} <16 bytes>}
1303 + digestEncrytionAlgorithm {pkcs-1 1}
1304 + encryptedDigest "encrypted message digest of the authenticated
1305 + attributes using the CA's [RA's] private key"
1308 +CertRep PKIMessage ::= {
1309 + contentType {pkcs-7 2}
1310 + content CertRepSigned
1313 +5.1.2.2 Failure Response
1315 +In this case, the CertRep sent back to the requester is same as in
1316 +the PENDING case, except that the pkiStatus attribute is set to FAILURE,
1317 +and the failInfo attribute should be included:
1319 + pkistatus {{id-attributes pkiStatus(3)} "FAILURE"}
1320 + failInfo {{id-attributes failInfo(4)} "the reason to reject"}
1322 +
\fLiu/Madson/McGrew/Nourse [Page 21]
1324 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1326 +5.1.2.3 SUCCESS response
1328 +In this case, the information portion of CertRep will be a degenerated
1329 +PKCS#7 which contains the requester's certificate. It is then enveloped
1330 +and signed as below:
1332 +pkcsCertRep SignedData ::= { -- PKCS#7
1334 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1335 + digestAlgorithm(2) 5}
1336 + contentInfo { -- empty content since this is degenerated PKCS#7
1337 + contentType {pkcs-7 1}
1340 + certificate { -- issued requester's certificate // must be first
1342 + serialNumber "issued requester's certificate serial number"
1343 + signature {pkcs-1 4} -- md5WithRSAEncryption
1344 + issuer "the certificate authority issuer name"
1346 + notBefore "UTC time"
1347 + notAfter "UTC time"
1349 + subject "the requester subject name as given in PKCS#10"
1350 + subjectPublicKeyInfo {
1351 + algorithm {pkcs-1 1}
1352 + subjectPublicKey "a DER encoding of requester public
1353 + key as given in PKCS#10"
1355 + extensions " the extensions as given in PKCS#10"
1356 + signatureAlgorithm {pkcs-1 4}
1357 + signature " the certificate authority signature"
1359 + certificate "the certificate authority certificate" (optional)
1360 + certificate "the registration authority certificate(s)" (optional)
1363 +pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7
1367 + issuerAndSerialNumber { -- use issuer name and serial number as
1368 + -- conveyed in requester's self-signed
1369 + -- certificate, included in the PKCSReq
1370 + issuer "the requester's subject name"
1371 + serialNumber "the serial number defined by the requester in
1372 + its self-signed certificate"
1374 + keyEncryptionAlgorithm {pkcs-1 1}
1375 + encryptedKey "content-encrypt key encrypted by the requester's
1376 + public key which is same key as authenticated in
1377 + the requester's certificate"
1381 +
\fLiu/Madson/McGrew/Nourse [Page 22]
1383 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1385 + encryptedContentInfo {
1386 + contentType {pkcs-7 1} -- data content identifier
1387 + contentEncryptionAlgorithm "OID for DES encryption"
1388 + encryptedContent "encrypted pkcsCertRep using content encryption
1392 +pkcsCertRepSigned SignedData ::= { -- PKCS#7
1394 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1395 + digestAlgorithm(2) 5}
1397 + contentType {pkcs-7 1}
1398 + content pkcsCertRepEnvelope
1402 + issuerAndSerialNumber {
1403 + issuer "the certificate authority issuer name"
1404 + serialNumber "the CA certificate's serial number"
1406 + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
1407 + digestAlgorithm(2) 5}
1408 + authenticateAttributes {
1409 + contentType {{pkcs-9 3} {pkcs-7 1}}
1410 + messageDigest {{pkcs-9 4} "a octet string"}
1411 + messageType {{id-attribute messageType(2)} "CertRep"}
1412 + transaction-id {{id-attributes transId(7)} "printable
1414 + -- same transaction id as given in PKCSReq
1415 + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"}
1416 + recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>}
1417 + senderNonce {{ id-attributes senderNonce(5) <16 bytes>}
1419 + digestEncryptionAlgorithm {pkcs-1 1}
1420 + encryptedDigest "encrypted digest of authenticate attributes
1421 + using CA's private key "
1424 +CertRep PKIMessage ::= {
1425 + contentType {pkcs-7 2}
1426 + content pkcsCertRepSigned
1429 +5.2 Poll for Requester Initial Certificate
1431 +Either triggered by the PENDING status received from the CertRep, or by
1432 +the non-response timeout for the previous PKCSReq, a requester will
1433 +enter the polling state by periodically sending GetCertInitial to the
1434 +server, until either the request is granted and the certificate is sent
1435 +back, or the request is rejected, or the configured time limit for
1436 +polling is exceeded.
1439 +
\fLiu/Madson/McGrew/Nourse [Page 23]
1441 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1444 +Since GetCertInitial is part of the enrollment, the messages exchanged
1445 +during the polling period should carry the same transaction identifier
1446 +as the previous PKCSReq.
1449 + Either the requester has received a CertRep with pkiStatus set to be
1450 + PENDING, or the previous PKCSReq has timed out.
1453 + The requester has either received the certificate, or be rejected of
1454 + its request, or the polling period ended as a failure.
1456 +5.2.1 GetCertInitial Message Format
1458 +Since at this time the certificate has not been issued, the requester
1459 +can only use the requester's subject name, combined with the
1460 +transaction identifier, to identify the polled certificate request.
1462 +The certificate authority server must be able to uniquely identify the
1463 +polled certificate request. A subject name can have more than one
1464 +outstanding certificate request (with different key usage attributes).
1466 +-- Information portion
1468 +pkcsGetCertInitial issuerAndSubject ::= {
1469 + issuer "the certificate authority issuer name"
1470 + subject "the requester subject name as given in PKCS#10"
1472 +pkcsGetCertInitialEnvelope EnvelopedData ::= {
1476 + issuerAndSerialNumber {
1477 + issuer "the CA issuer name"
1478 + serialNumber "the CA certificate serial number"
1480 + keyEncryptionAlgorithm {pkcs-1 1}
1481 + encryptedKey "content-encrypt key encrypted by CA's public key"
1483 + encryptedContentInfo {
1484 + contentType {pkcs-7 1} -- data content
1485 + contentEncryptionAlgorithm "OID for DES encryption"
1486 + encryptedContent "encrypted getCertInital"
1489 +pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7
1491 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1492 + digestAlgorithm(2) 5}
1494 + contentType {pkcs-7 1}
1497 +
\fLiu/Madson/McGrew/Nourse [Page 24]
1499 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1501 + content pkcsGetCertIntialEnvelope
1503 + certificate { -- the requester's self-signed certificate
1505 + serialNumber "the transaction id associated with enrollment"
1506 + signature {pkcs-1 4} -- md5WithRSAEncryption
1507 + issuer " the requester's subject name"
1509 + notBefore "a UTC time"
1510 + notAfter "a UTC time"
1512 + subject "the requester's subject name"
1513 + subjectPublicKeyInfo {
1514 + algorithm {pkcs-1 1}
1515 + subjectPublicKey "DER encoding of requester's public key"
1517 + signatureAlgorithm {pkcs-1 4}
1518 + signature "the signature generated by using the requester's
1519 + private key corresponding to the public key in
1520 + this certificate."
1524 + issuerAndSerialNumber {
1525 + issuer "requester's subject name"
1526 + serialNumber "the transaction id used in previous PKCSReq"
1528 + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
1529 + digestAlgorithm(2) 5}
1530 + authenticateAttributes {
1531 + contentType {{pkcs-9 3} {pkcs-7 1}}
1532 + messageDigest {{pkcs-9 4} "an octet string"}
1533 + -- digest of getCertInitial
1534 + messageType {{id-attribute messageType(2)} "GetCertInitial"}
1535 + transaction-id {{id-attributes transId(7)} "printable
1537 + -- same transaction idused in previous PKCSReq
1538 + senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>}
1540 + digestEncryptionAlgorithm {pkcs-1 1}
1541 + encryptedDigest "encrypted digest of authenticateAttributes"
1544 +GetCertInitial PKIMessage ::= {
1545 + contentType {pkcs-7 2}
1546 + content pkcsGetCertInitialSigned
1551 +5.2.2 GetCertInitial Response Message Format
1553 +The response messages for GetCertInitial are the same as for PKCSReq.
1555 +
\fLiu/Madson/McGrew/Nourse [Page 25]
1557 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1559 +5.3 Certificate Access
1561 +The certificate query message defined in this section is an option when
1562 +the LDAP server is not available to provide the certificate query. A
1563 +requester should be able to query an issued certificate from the
1564 +certificate authority, as long as the issuer name and the issuer
1565 +assigned certificate serial number is known to the requesting end
1566 +entity. This transaction is not intended to provide the service as a
1567 +certificate directory service. A more complicated query mechanism would
1568 +have to be defined in order to allow a requester to query a certificate
1569 +using various different fields.
1571 +This transaction consists of one GetCert message sent to the server by
1572 +a requester, and one CertRep message sent back from the server.
1575 + The queried certificate have been issued by the certificate authority
1576 + and the issuer assigned serial number is known.
1579 + Either the certificate is sent back or the request is rejected.
1582 +5.3.1 GetCert Message Format
1584 +The queried certificate is identified by its issuer name and the issuer
1585 +assigned serial number. If this is a query for an arbitrary requester's
1586 +certificate, the requesting requester should includes its own CA issued
1587 +certificate in the signed envelope. If this is a query for its own
1588 +certificate (assume the requester lost the issued certificate, or does
1589 +not have enough non-volatile memory to save the certificate), then the
1590 +self-signed certificate has to be included in the signed envelope.
1592 + pkcsGetCert issuerAndSerialNumber ::= {
1593 + issuer "the certificate issuer name"
1594 + serialNumber "the certificate serial number"
1596 + pkcsGetCertEnvelope EnvelopedData ::= {
1600 + issuerAndSerialNumber {
1601 + issuer "the CA [RA] issuer name"
1602 + serialNumber "the CA [RA] certificate serial number"
1604 + keyEncryptionAlgorithm {pkcs-1 1}
1605 + encryptedKey "content-encrypt key encrypted
1606 + by CA [RA] public key"
1613 +
\fLiu/Madson/McGrew/Nourse [Page 26]
1615 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1618 + encryptedContentInfo {
1619 + contentType {pkcs-7 1} -- data content
1620 + contentEncryptionAlgorithm "OID for DES encryption"
1621 + encryptedContent "encrypted pkcsGetCert using the content
1625 + pkcsGetCertSigned SignedData ::= {
1627 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1628 + digestAlgorithm(2) 5}
1630 + contentType {pkcs-7 1}
1631 + content pkcsGetCertEnvelope
1634 + certificate "CA issued certificate"
1635 + or "self-signed certificate"
1639 + issuerAndSerialNumber {
1640 + issuer "the requester's subject name"
1641 + serialNumber "requester's certificate serial number"
1643 + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
1644 + digestAlgorithm(2) 5}
1645 + authenticateAttributes {
1646 + contentType {{pkcs-9 3} {pkcs-7 1}}
1647 + messageDigest {{pkcs-9 4} "an octet string"}
1648 + -- digest of pkcsGetCertEnvelope
1649 + messageType {{id-attribute messageType(2)} "GetCert"}
1650 + transaction-id {{id-attributes transId(7)} "printable
1652 + senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
1654 + digestEncryptionAlgorithm {pkcs-1 1}
1655 + encryptedDigest "encrypted digest of authenticateAttributes"
1658 + GetCert PKIMessage ::= {
1659 + contentType {pkcs-7 2}
1660 + content pkcsGetCertSigned
1671 +
\fLiu/Madson/McGrew/Nourse [Page 27]
1673 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1676 +5.3.2 CertRep Message Format
1678 +In this case, the CertRep from the server is same as the CertRep for the
1679 +PKCSReq, except that the server will only either grant the request or
1680 +reject the request. Also, the recipientInfo should use the CA issuer
1681 +name and CA assigned serial number to identify the requester's key pair
1682 +since at this time, the requester has received its own certificate.
1686 +The CRL query message defined in this section is an option when the LDAP
1687 +server is not available to provide the CRL query. In the PKI protocol
1688 +proposed here, only the requester can initiate the transaction to
1689 +download CRL. A requester sends GetCRL request to the server and the
1690 +server sends back CertRep whose information portion is a degenerated
1691 +PKCS#7 which contains only the most recent CRL. The size of CRL included
1692 +in the CertRep should be determined by the implementation.
1695 + The certificate authority certificate has been downloaded to the end
1699 + CRL sent back to the requester.
1701 +5.4.1 GetCRL Message format
1703 +The CRL is identified by using both CA's issuer name and the CA
1704 +certificate's serial number:
1706 + pkcsGetCRL issuerAndSerialNumber {
1707 + issuer "the certificate authority issuer name"
1708 + serialNumber "certificate authority certificate's serial number"
1711 +When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as
1714 + pkcsGetCRL SEQUENCE {
1715 + crlIssuer issuerAndSerialNumber
1716 + distributionPoint CE-CRLDistPoints
1719 +where CE-CRLDisPoints is defined in X.509, but must contain only one
1720 +CRL distribution point.
1731 +
\fLiu/Madson/McGrew/Nourse [Page 28]
1733 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1735 + pkcsGetCRLEnvelope EnvelopedData ::= {
1739 + issuerAndSerialNumber {
1740 + issuer "the certificate authority (or RA) issuer name"
1741 + serialNumber "the CA (RA) certificate's serial number"
1743 + keyEncryptionAlgorithm {pkcs-1 1}
1744 + encryptedKey "content-encrypt key encrypted by CA (RA) public key"
1746 + encryptedContentInfo {
1747 + contentType {pkcs-7 1} -- data content
1748 + contentEncryptionAlgorithm "OID for DES encryption"
1749 + encryptedContent "encrypted pkcsGetCRL"
1752 + pkcsGetCRLSigned SignedData ::= {
1754 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1755 + digestAlgorithm(2) 5}
1757 + contentType {pkcs-7 1}
1758 + content pkcsGetCRLEnvelope
1761 + certificate "CA-issued or self-signed requester's certificate"
1765 + issuerAndSerialNumber {
1766 + issuer "the requester's issuer name"
1767 + serialNumber "the requester's certificate serial number"
1769 + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
1770 + digestAlgorithm(2) 5}
1771 + authenticateAttributes {
1772 + contentType {{pkcs-9 3} {pkcs-7 1}}
1773 + messageDigest {{pkcs-9 4} 0x<16/20 bytes>}
1774 + -- digest of pkcsGetCRLEnvelope
1775 + messageType {{id-attribute messageType(2)} "CertCRL"}
1776 + transaction-id {{id-attributes transId(7)} "printable
1778 + senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
1780 + digestEncryptionAlgorithm {pkcs-1 1}
1781 + encryptedDigest "encrypted digest of authenticateAttributes"
1784 + GetCRL PKIMessage ::= {
1785 + contentType {pkcs-7 2}
1786 + content pkcsGetCRLSigned
1789 +
\fLiu/Madson/McGrew/Nourse [Page 29]
1791 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1794 +5.4.2 CertRep Message Format
1796 +The CRL is sent back to the requester through CertRep message. The
1797 +information portion of this message is a degenerated PKCS#7 SignedData
1798 +which contains only a CRL.
1800 + pkcsCertRep SignedData ::= {
1802 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1803 + digestAlgorithm(2) 5}
1805 + contentType {pkcs-7 1}
1808 + signature {pkcs-1 4}
1809 + issuer "the certificate authority issuer name"
1810 + lastUpdate "UTC time"
1811 + nextUpdate "UTC time"
1812 + revokedCertificate {
1813 + -- the first entry
1814 + userCertificate "certificate serial number"
1815 + revocationData "UTC time"
1818 + userCertificate "certificate serial number"
1819 + revocationData "UTC time"
1822 + pkcsCertRepEnvelope EnvelopedData ::= {
1826 + issuerAndSerialNumber {
1827 + issuer "the requester's issuer name"
1828 + serialNumber "the requester certificate serial number"
1830 + keyEncryptionAlgorithm {pkcs-1 1}
1831 + encryptedKey "content-encrypt key encrypted by requester's
1834 + encryptedContentInfo {
1835 + contentType {pkcs-7 1} -- data content
1836 + contentEncryptionAlgorithm "OID for DES encryption"
1837 + encryptedContent "encrypted pkcsCertRep using requester's
1847 +
\fLiu/Madson/McGrew/Nourse [Page 30]
1849 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1852 + pkcsCertRepSigned SignedData ::= { -- PKCS#7
1854 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1855 + digestAlgorithm(2) 5}
1857 + contentType {pkcs-7 1}
1858 + content pkcsCertRepEnvelope
1862 + issuerAndSerialNumber {
1863 + issuer "the certificate authority issuer name"
1864 + serialNumber "the CA certificate's serial number"
1866 + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549)
1867 + digestAlgorithm(2) 5}
1868 + authenticateAttributes {
1869 + contentType {{pkcs-9 3} {pkcs-7 1}}
1870 + messageDigest {{pkcs-9 4} "an octet string"}
1871 + -- digest of pkcsCertRepEnvelope
1872 + messageType {{id-attribute messageType(2)} "CertRep"}
1873 + transaction-id {{id-attributes transId(7)} "printable
1875 + -- same transaction id as given in PKCSReq
1876 + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"}
1877 + recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>}
1878 + senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>}
1880 + digestEncryptionAlgorithm {pkcs-1 1}
1881 + encryptedDigest "encrypted digest of authenticatedAttributes
1882 + using CA private key"
1887 +NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but
1888 +SCEP entities must also accept a sequence of octet strings as a valid
1889 +alternate encoding.
1891 +This alternate encoding must be accepted wherever PKCS #7 Enveloped
1892 +Data is specified in this document.
1904 +
\fLiu/Madson/McGrew/Nourse [Page 31]
1906 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
1908 +5.5 Get Certificate Authority Certificate
1910 +Before any transaction begins, end entities have to get the CA (and
1911 +possibly RA) certificate(s) first. Since the requester may have no CA
1912 +certificates or CA public keys at all, this message can not be
1913 +encrypted and the response must be authenticated by out-of-band means.
1914 +These certs are obtained by means of an HTTP GET message. To get the
1915 +CA certificate, the requester does a "HTTP GET" with a URL that
1916 +identifies a CGI script on the server and an optional CA issuer
1917 +identifier as the parameter to the CGI script. The response is either
1918 +a single X.509 CA certificate ("CA mode"), or a PKCS7 message
1919 +containing the CA certificate and RA certificates ("RA mode"). The
1920 +client can determine which mode the CA operates in by which response
1921 +it gets. Once the CA certificate is received by the requester, a
1922 +fingerprint is generated using either the SHA-1 or the MD5 hash
1923 +algorithm on the whole CA certificate. If the requester does not have
1924 +a certificate path to a trusted CA certificate, this fingerprint may
1925 +be used to verify the certificate, by some positive out-of-band means,
1926 +such as a phone call.
1928 +5.5.1 GetCACert HTTP Message Format
1929 + "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT
1931 + CGI-PATH defines the actual CGI path to invoke the CGI program
1932 + which parses the request.
1933 + CGI-PROG is set to be the string "pkiclient.exe" and this is
1934 + expected to be the program that the CA will use to handle the
1935 + SCEP transactions.
1936 + CA-IDENT is any string which is understood by the CA.
1937 + For example, it could be a domain name like ietf.org.
1938 + If a certificate authority has multiple CA certificates
1939 + this field can be used to distinguish which is required.
1940 + Otherwise it may be ignored.
1944 +The response for GetCACert is different between the case where the CA
1945 +directly communicated with the requester during the enrollment, and the
1946 +case where a RA exists and the requester communicates with the RA
1947 +during the enrollment.
1949 +5.5.2.1 CA Certificate Only Response
1951 +A binary X.509 CA certificate is sent back as a MIME object with a
1952 +Content-Type of application/x-x509-ca-cert.
1954 +5.5.2.2 CA and RA Certificates Response
1956 +When an RA exists, both CA and RA certificates must be sent back in
1957 +the response to the GetCACert request. The RA certificate(s) must be
1958 +signed by the CA. A certificates-only PKCS#7 SignedData is used to
1959 +carry the certificates to the requester, with a Content-Type of
1960 +application/x-x509-ca-ra-cert.
1962 +
\fLiu/Madson/McGrew/Nourse [Page 32]
1964 +5.5.3 Get Next Certificate Authority Certificate
1966 +5.5.3.1 GetNextCACert HTTP Message Format
1967 + "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT
1969 +The response to this message is a PKCS#7 certificates-only message containing
1970 +a CA certificate (and possibly RA certificates) to be used when the current CA
1971 +certificate expires, signed with the current CA cert (or RA certificate, if
1972 +the CA is in RA mode. Note that a PKCS#7 is returned even in CA mode.
1974 +5.5.3.2 GetCACaps HTTP Message Format
1975 + "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT
1977 +This message requests capabilities from CA. The response is a list of
1978 +text capabilities, as defined in Appendix F. Support for this message
1979 +is optional, but if it is not supported, the client should assume that
1980 +none of the capabilities in Appendix F are supported.
1982 +5.6 Get Certificate Authority Certificate Chain
1984 +GetCACertChain provides a way to get the entire certificate chain.
1986 +5.6.1 GetCACertChain HTTP Message Format
1988 + "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT
1989 + where CGI-SCRIPT and CA-IDENT are as described for GetCACert.
1993 +The response for GetCACertChain is a certificates-only PKCS#7 SignedData
1994 +to carry the certificates to the requester, with a Content-Type of
1995 +application/x-x509-ca-ra-cert-chain.
1997 +5.6.3 Backwards Compatability
1999 +Versions of SCEP prior to revision 3 do not support GetCACertChain.
2000 +Certificate Authorities written to these prior versions will not be
2001 +able to process the message and may return an HTML error.
2003 +To avoid this, clients should send the GetCACert message first. If the
2004 +returned certificate is self-signed or is signed by a Certificate
2005 +Authority that is trusted by the client, then it is not necessary to
2006 +send the GetCACertChain message and it should not be sent.
2008 +If a Certificate Authority is configured with a certificate that is
2009 +not either self-signed or has a self-signed issuer, then it should
2010 +support this message. In other words, it should be supported if the
2011 +CA hierarchy is more than two-deep.
2013 +An old CA in a two-deep hierarchy might still get this message from
2014 +a client if the client did not trust either that CA or its issuer.
2015 +In that event, the certificate cannot be trusted anyway. In any case
2016 +the CA must not crash or hang upon the receipt of the message and the
2017 +client must be able to handle whatever error is returned by the CA,
2018 +including an HTML error or an ungraceful disconnect.
2020 +
\fLiu/Madson/McGrew/Nourse [Page 33]
2022 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2024 +The following is the ASN.1 definition of Cert-Only PKCS#7:
2026 + certOnly SignedData ::= {
2028 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
2029 + digestAlgorithm(2) 5}
2032 + contentType {pkcs-7 1} -- data content identifier
2035 + certificates -- the RA and CA certificates.
2038 + CARACerts PKIMessage ::= { -- special pki message sent in the clear
2039 + contentType {pkcs-7 2}
2044 +6.0 Security Considerations
2046 +This entire document is about security. Common security considerations
2047 +such as keeping private keys truly private and using adequate lengths
2048 +for symmetric and asymmetric keys must be followed in order to maintain
2049 +the security of this protocol.
2052 +7.0 Intellectual Property
2054 +This protcol includes the optional use of Certificate Revocation List
2055 +Distribution Point (CRLDP) technology, which is a patented technology
2056 +of Entrust Technologies, Inc. (Method for Efficient Management of
2057 +Certificate Revocation Lists and Update Information (U.S. Patent
2058 +5,699,431)). Please contact Entrust Technologies, Inc.
2059 +(www.entrust.com) for more information on licensing CRLDP technology.
2064 +[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
2065 +1.5", RFC 2315, March 1998.
2067 +[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version
2068 +1.5", RFC 2314, March 1998.
2070 +[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key
2071 +Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
2078 +
\fLiu/Madson/McGrew/Nourse [Page 34]
2080 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2082 +Appendix A: Cisco Requester Subject Name Definition
2084 +The ip address and the FQDN of a SCEP client should be included in the
2085 +V3 extension subjectAltName. When the subjectAltName extension attribute
2086 +is present, both the subjectAltName fields and the subjectName field could
2087 +have the IP address and the FQDN information.
2089 +When the X.500 directory is used by the CA to define the name space, the
2090 +subject name defined above become a RDN which is part of DN binded to
2091 +the requester's public key in the certificate.
2094 +A sample of DN assigned by Entrust CA is given below (assume the same
2095 +ciscoRouterAlice is used as the requester defined subject name):
2097 + OU = InteropTesting, O = Entrust Technologies, C = CA
2098 + RDN = {"alice.cisco.com", "172.21.114.67", "22334455"}
2101 +
\fLiu/Madson/McGrew/Nourse [Page 35]
2103 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2105 +Appendix B: IPSEC Client Enrollment Certificate Request
2107 +The following is the certificate enrollment request (PKCS#10) as created
2108 +by Cisco VPN Client:
2110 +-----END NEW CERTIFICATE REQUEST-----
2111 + 0 30 439: SEQUENCE {
2112 + 4 30 288: SEQUENCE {
2114 + 11 30 57: SEQUENCE {
2116 + 15 30 53: SEQUENCE {
2117 + 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
2118 + 22 13 46: PrintableString
2119 + : 'For Xiaoyi, IPSEC attrs in alternate name
2124 + 70 30 158: SEQUENCE {
2125 + 73 30 13: SEQUENCE {
2126 + 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1
2130 + 88 03 140: BIT STRING 0 unused bits
2131 + : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E
2132 + : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2
2133 + : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6
2134 + : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4
2135 + : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F
2136 + : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA
2137 + : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19
2138 + : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18
2139 + : [ Another 11 bytes skipped ]
2142 + 233 30 61: SEQUENCE {
2143 + 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9
2146 + 248 30 46: SEQUENCE {
2147 + 250 30 44: SEQUENCE {
2148 + 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
2149 + 257 04 37: OCTET STRING
2150 + 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69
2153 +
\fLiu/Madson/McGrew/Nourse [Page 36]
2155 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2157 + 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64
2158 + 6E 2E 69 72 65 2E 63 6F 6D
2166 + 296 30 13: SEQUENCE {
2167 + 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549
2171 + 311 03 129: BIT STRING 0 unused bits
2172 + : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A
2173 + : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60
2174 + : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7
2175 + : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D
2176 + : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91
2177 + : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0
2178 + : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24
2179 + : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7
2183 +Appendix C: Private OID Definitions
2185 +The OIDs used in defining pkiStatus are VeriSign self-maintained
2186 +OIDs. Please note, work is in progress to replace the VeriSign owned
2187 +object identifiers with the standard object identifiers. Once the
2188 +standarlization is completed, this documentation will be updated.
2190 +id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)}
2191 +id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)}
2192 +id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)}
2193 +id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)}
2194 +id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)}
2195 +id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)}
2196 +id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)}
2197 +id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)}
2198 +id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)}
2199 +id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)}
2202 +
\fLiu/Madson/McGrew/Nourse [Page 37]
2204 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2206 + Appendix D: CRL Query by means of LDAP
2208 + In order to retrieve the CRL by means of LDAP, the client needs to know
2209 + where in the directory it is stored. The certificate must contain a
2210 + CRL Distribution Point extension encoded as a DN or as an LDAP URI.
2212 +For example, the certificate issued by Entrust VPN contains
2213 +the following DN as the CRL distribution point:
2217 +CN = CRL1, O = cisco, C = US.
2219 + The asn.1 encoding of this distribution point is:
2221 + 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06
2222 + 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03
2226 +The ldap form would be:
2228 +ldap://servername/CN=CRL1,O=cisco,C=US
2232 +Appendix E: SCEP State Transitions
2234 +SCEP state transitions are based on transaction identifier. The design
2235 +goal is to ensure the synchronization between the CA and the requester
2236 +under various error situations.
2239 +An identity is defined by the combination of FQDN, the IP address and
2240 +the client serial number. FQDN is the required name attribute. It is
2241 +important to notice that, a client named as Alice.cisco.com is different
2242 +from the client named as Alice.cisco.com plus IPAddress 117.96.1.219.
2244 +Each enrollment transaction is uniquely associated with a transaction
2245 +identifier. Because the enrollment transaction could be interrupted by
2246 +various errors, including network connection errors or client reboot,
2247 +the SCEP client generates a transaction identifier by calculating a
2248 +hash on the public key value for which the enrollment is requested. This
2249 +retains the same transaction identifier throughout the enrollment
2250 +transaction, even if the client has rebooted or timed out, and issues a
2251 +new enrollment request for the same key pair. It also provides the way
2252 +for the CA to uniquely identify a transaction in its database. At the
2253 +requester side, it generates a transaction identifier which is included
2254 +in PKCSReq. If the CA returns a response of PENDING, the requester
2255 +will poll by periodically sending out GetCertInitial with the same
2256 +transaction identifier until either a response other than PENDING is
2257 +obtained, or the configured maximum time has elapsed.
2259 +If the client times out or the client reboots, the client administrator
2260 +will start another enrollment transaction with the same key pair. The
2261 +second enrollment will have the transaction idenifier. At the server
2262 +side, instead of accepting the PKCSReq as a new enrollment request, it
2263 +should respond as if another GetCertInitial message had been sent with
2264 +that transaction ID. In another word, the second PKCSReq should be
2265 +taken as a resynchronization message to allow the enrollment resume as
2266 +the same transaction.
2268 +It is important to keep the transaction id unique since SCEP requires the
2269 +same policy and same identity be applied to the same subject name and
2272 +
\fLiu/Madson/McGrew/Nourse [Page 38]
2274 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2276 +key pair binding. In the current implementation, an SCEP client can
2277 +only assume one identity. At any time, only one key pair, with a given
2278 +key usage, can be associated with the same identity.
2280 +The following gives several examples of client to CA transactions.
2282 +Client actions are indicated in the left column, CA actions are
2283 +indicated in the right column. A blank action signifies that no message
2284 +was received. Note that these examples assume that the CA enforces the
2285 +certificate-name uniqueness property defined in Section 2.1.1.1.
2287 +The first transaction, for example, would read like this:
2288 + "Client Sends PKCSReq message with transaction ID 1 to the
2289 + CA. The CA signs the certificate and constructs a CertRep Message
2290 + containing the signed certificate with a transaction ID 1. The client
2291 + receives the message and installs the cert locally."
2293 +Successful Enrollment Case: no manual authentication
2294 +PKCSReq (1) ----------> CA Signs Cert
2295 +Client Installs Cert <---------- CertRep (1) SIGNED CERT
2299 +Successful Enrollment Case: manual authentication required
2300 +PKCSReq (10) ----------> Cert Request goes into Queue
2301 +Client Polls <---------- CertRep (10) PENDING
2302 +GetCertInitial (10) ----------> Still pending
2303 +Client Polls <---------- CertRep (10) PENDING
2304 +GetCertInitial (10) ----------> Still pending
2305 +Client Polls <---------- CertRep (10) PENDING
2306 +GetCertInitial (10) ----------> Still pending
2307 +Client Polls <---------- CertRep (10) PENDING
2308 +GetCertInitial (10) ----------> Cert has been signed
2309 +Client Installs Cert <---------- CertRep (10) SIGNED CERT
2313 +Resync Case - CA Receive and Signs PKCSReq, Client Did not receive
2316 +PKCSReq (3) ----------> Cert Request goes into queue
2317 + <---------- CertRep (3) PENDING
2318 +GetCertInitial (3) ---------->
2319 + <---------- CertRep (3) PENDING
2320 +GetCertInitial (3) ----------->
2321 + <----------- CA signed Cert and sent back
2324 +PKCSReq (3) ----------> Cert already signed, sent back to
2326 +Client Installs Cert <---------- CertRep (3) SIGNED CERT
2330 +
\fLiu/Madson/McGrew/Nourse [Page 39]
2332 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2335 +Case when NVRAM is lost and client has to generate a new key pair, there
2336 +is no change of name information:
2338 +PKCSReq (4) ----------> CA Signs Cert
2339 +Client Installs Cert <---------- CertRep (4) SIGNED CERT
2340 +(Client looses Cert)
2341 +PKCSReq (5) ----------> There is already a valid cert with
2343 +Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR
2344 +PKCSReq (5) ----------> CA Signs Cert
2345 +Client Installs Cert <---------- CertRep (5) SIGNED CERT
2348 +Case when client admin resync the enrollment using a different PKCS#10:
2349 +PKCSReq (6) ----------> CA Signs Cert
2350 + <---------- CertRep (6) SIGNED CERT
2351 +(Client timeout and admin starts another enrollment with a different
2352 + PKCS#10, but the same transaction id)
2353 +PKCSReq (6) with different PKCS#10
2354 + ----------> There is already a valid cert with
2355 + this entity (by checking FQDN).
2356 + <---------- CertRep (6) INVALID PKCS#10 CERT
2358 +Client admin either revokes the existing cert
2359 +or corrects the error by enrolling with
2360 +the same PKCS#10 as the first PKCSReq(6)
2361 +PKCSReq (6) ----------> CA find the existing Cert
2362 +Client Installs Cert <---------- CertRep (6) SIGNED CERT
2365 +Resync case when server is slow in response:
2366 +PKCSReq (13) ----------> Cert Request goes into Queue
2367 + <---------- CertRep (13) PENDING
2368 +GetCertInitial ----------> Still pending
2369 + <---------- CertRep (13) PENDING
2370 +GetCertInitial ----------> Still pending
2371 + <---------- CertRep (13) PENDING
2372 +GetCertInitial ----------> Still pending
2373 + <---------- CertRep (13) PENDING
2374 +GetCertInitial ----------> Still pending
2375 +(TimeOut) <---------- CertRep (13) PENDING
2377 +PKCSReq (13) ----------> Still pending
2378 +Client polls <---------- CertRep (13) PENDING
2379 +CertCertInitial ----------> Cert has been signed
2380 +Client Installs Cert <---------- CertRep (13) SIGNED CERT
2382 +PKCSReq (13) ----------> Cert has been signed
2383 +Client Installs Cert <---------- CertRep (13) SIGNED CERT
2388 +
\fLiu/Madson/McGrew/Nourse [Page 40]
2390 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2392 +Appendix F. CA Capabilities
2394 +The response for a GetCACaps message is a list of CA capabilities, in
2395 +plain text, separated by <LF> characters, as follows (quotation marks
2398 +Keyword Description
2400 +"GetNextCACert" CA Supports the GetNextCACert message.
2401 +"POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST.
2402 +"SHA-1" CA Supports the SHA-1 hashing algorithm in
2403 + signatures and fingerprints. If present, the
2404 + client SHOULD use SHA-1. If absent, the client
2405 + MUST use MD5 to maintain backward compatability.
2406 +"Renewal" Clients may use current certificate and key to
2407 + authenticate an enrollment request for a new
2410 +A client must be able to accept and ignore any unknown keywords that
2411 +might be sent back by a CA that implements a future version of SCEP.
2415 +GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca
2422 +This means that the CA supports the GetNextCACert message and allows
2423 +PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent
2427 +
\fLiu/Madson/McGrew/Nourse [Page 41]
2429 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2431 +Appendix G. Certificate Renewal and CA Key Rollover
2433 +To renew a client certificate, use the PKCSreq message and sign it with
2434 +the existing client certificate instead of a self-signed certificate.
2436 +To obtain the new CA certificate prior to the expiration of the current
2437 +one, use the GetNextCACert message if the CA supports it.
2439 +To obtain a new client certificate signed by the new CA certificate,
2440 +use the new CA or RA certificate in the message envelope.
2445 +GetNextCACert ---------->
2446 + <---------- CertRep (3) New CA certificate
2448 +PKCSReq* (1) ----------> CA Signs certificate with NEW key
2449 +Client Stores Cert <---------- CertRep (3) Certificate issued
2450 +for installation when from NEW CA certificate and keypair.
2451 +existing cert expires.
2454 +*enveloped for new CA or RA cert and keypair. The CA will use the
2455 +envelope to determine which key and certificate to use to issue the
2456 +client certificate.
2459 +
\fLiu/Madson/McGrew/Nourse [Page 42]
2461 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2463 +Appendix H. PKIOperation via HTTP POST Message
2465 +If the remote CA supports it, any of the PKCS#7-encoded SCEP messages
2466 +may be sent via HTTP POST instead of HTTP GET. This is allowed for
2467 +any SCEP message except GetCACert, GetCACertChain, GetNextCACert,
2468 +or GetCACaps. In this form of the message, Base 64 encoding is not
2471 +POST /cgi-bin/pkiclient.exe?operation=PKIOperation
2472 +<binary PKCS7 data>
2474 +The client can verify that the CA supports SCEP messages via POST by
2475 +looking for the "POSTPKIOperation" capability (See Appendix F).
2482 +
\fLiu/Madson/McGrew/Nourse [Page 43]
2484 +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005
2486 +Appendix Y. Author Contact Information
2488 +Xiaoyi Liu Cheryl Madson
2490 +510 McCarthy Drive 510 McCarthy Drive
2491 +Milpitas, CA Milpitas, CA.
2492 +xliu@cisco.com cmadson@cisco.com
2495 +David McGrew Andrew Nourse
2497 +170 West Tasman Drive 510 McCarthy Drive
2498 +San Jose, CA 94134 Milpitas, CA.
2499 +mcgrew@cisco.com nourse@cisco.com
2504 +Appendix Z. Copyright Section
2506 +Copyright (C) The Internet Society (2005). This document is subject
2507 +to the rights, licenses and restrictions contained in BCP 78, and
2508 +except as set forth therein, the authors retain all their rights.
2510 +This document and the information contained herein are provided on an
2511 +"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2512 +OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2513 +ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2514 +INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2515 +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2516 +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2521 +This draft expires 11 Aug 2005
2523 +[End of draft-nourse-scep-11.txt]
2525 diff -uN sscep/fileutils.c sscep-ng2/fileutils.c
2526 --- sscep/fileutils.c 2003-04-15 12:53:45.000000000 +0200
2527 +++ sscep-ng2/fileutils.c 2006-04-28 10:03:24.000000000 +0200
2530 STACK_OF(X509) *certs;
2532 + ASN1_BIT_STRING *cert_pubkey = NULL;
2535 + ASN1_BIT_STRING *request_pubkey =
2536 + request->req_info->pubkey->public_key;
2543 for (i = 0; i < sk_X509_num(certs); i++) {
2544 - char buffer[1024];
2546 cert = sk_X509_value(certs, i);
2547 + cert_pubkey = X509_get_X509_PUBKEY(cert)->public_key;
2548 +#define fu_print_name(n) \
2549 + X509_NAME_print_ex_fp(stdout,(n),0,XN_FLAG_RFC2253|ASN1_STRFLGS_SHOW_TYPE)
2551 - printf("%s: found certificate with\n"
2552 - " subject: %s\n", pname,
2553 - X509_NAME_oneline(X509_get_subject_name(cert),
2554 - buffer, sizeof(buffer)));
2555 - printf(" issuer: %s\n",
2556 - X509_NAME_oneline(X509_get_issuer_name(cert),
2557 - buffer, sizeof(buffer)));
2558 + printf("%s: found certificate with\n subject: ", pname);
2559 + fu_print_name(X509_get_subject_name(cert));
2560 + printf("\n issuer: ");
2561 + fu_print_name(X509_get_issuer_name(cert));
2564 - /* The subject has to match that of our request */
2565 - if (!X509_NAME_cmp(X509_get_subject_name(cert),
2566 + /* The public keys of the request and certificate must match */
2567 + if (M_ASN1_BIT_STRING_cmp(request_pubkey,cert_pubkey) != 0) {
2569 + printf(" public keys of request and certificate don't match\n");
2572 + /* The subject has to match that of our request,
2573 + if the "Compare subject DN" flag is set */
2574 + if (C_flag && X509_NAME_cmp(X509_get_subject_name(cert),
2575 X509_REQ_get_subject_name(request))) {
2577 - /* The subject cannot be the issuer (selfsigned) */
2578 - if (X509_NAME_cmp(X509_get_subject_name(cert),
2579 - X509_get_issuer_name(cert))) {
2583 + printf(" certificate subject names doesn't match request subject name:\n ");
2584 + fu_print_name(X509_REQ_get_subject_name(request));
2590 +#undef fu_print_name
2591 + /* The subject cannot be the issuer (selfsigned) */
2592 + if (!X509_NAME_cmp(X509_get_subject_name(cert),
2593 + X509_get_issuer_name(cert))) {
2595 + printf(" certificate is self signed\n");
2601 if (localcert == NULL) {
2602 fprintf(stderr, "%s: cannot find requested certificate\n",
2603 @@ -320,34 +338,36 @@
2604 /* Read local certificate (GetCert and GetCrl) */
2607 -read_local_cert(void) {
2608 - if (!l_flag || !(localfile = fopen(l_char, "r"))) {
2609 - fprintf(stderr, "%s: cannot open local cert file\n", pname);
2610 +read_cert(X509** cert, char* filename) {
2612 + if (!(file = fopen(filename, "r"))) {
2613 + fprintf(stderr, "%s: cannot open cert file %s\n", pname, filename);
2614 exit (SCEP_PKISTATUS_FILE);
2616 - if (!PEM_read_X509(localfile, &localcert, NULL, NULL)) {
2617 - fprintf(stderr, "%s: error while reading local cert\n", pname);
2618 + if (!PEM_read_X509(file, cert, NULL, NULL)) {
2619 + fprintf(stderr, "%s: error while reading cert %s\n", pname, filename);
2620 ERR_print_errors_fp(stderr);
2621 exit (SCEP_PKISTATUS_FILE);
2623 - fclose(localfile);
2627 /* Read private key */
2631 +read_key(EVP_PKEY** key, char* filename) {
2633 /* Read private key file */
2634 - if (!k_flag || !(keyfile = fopen(k_char, "r"))) {
2635 - fprintf(stderr, "%s: cannot open private key file\n", pname);
2636 + if (!(file = fopen(filename, "r"))) {
2637 + fprintf(stderr, "%s: cannot open private key file %s\n", pname, filename);
2638 exit (SCEP_PKISTATUS_FILE);
2640 - if (!PEM_read_PrivateKey(keyfile, &rsa, NULL, NULL)) {
2641 - fprintf(stderr, "%s: error while reading private key\n", pname);
2642 + if (!PEM_read_PrivateKey(file, key, NULL, NULL)) {
2643 + fprintf(stderr, "%s: error while reading private key %s\n", pname, filename);
2644 ERR_print_errors_fp(stderr);
2645 exit (SCEP_PKISTATUS_FILE);
2651 /* Read PKCS#10 request */
2652 diff -uN sscep/init.c sscep-ng2/init.c
2653 --- sscep/init.c 2003-01-31 10:07:16.000000000 +0100
2654 +++ sscep-ng2/init.c 2006-04-28 10:11:40.000000000 +0200
2656 if (!(i_char = strdup(str2)))
2659 + } else if (!strncmp(str1, "CheckSubjectName", 16)) {
2660 + if (!strncmp(str2, "yes", 3) && !C_flag)
2662 } else if (!strncmp(str1, "CertReqFile", 11)) {
2665 @@ -114,6 +117,12 @@
2666 if (!(l_char = strdup(str2)))
2669 + } else if (!strncmp(str1, "SignCertFile", 12)) {
2672 + if (!(O_char = strdup(str2)))
2675 } else if (!strncmp(str1, "MaxPollCount", 12)) {
2678 @@ -130,6 +139,12 @@
2679 if (!(k_char = strdup(str2)))
2682 + } else if (!strncmp(str1, "SignKeyFile", 11)) {
2685 + if (!(K_char = strdup(str2)))
2688 } else if (!strncmp(str1, "SelfSignedFile", 15)) {
2691 diff -uN sscep/pkcs7.c sscep-ng2/pkcs7.c
2692 --- sscep/pkcs7.c 2003-02-10 06:04:48.000000000 +0100
2693 +++ sscep-ng2/pkcs7.c 2006-04-26 13:40:34.000000000 +0200
2696 PKCS7_SIGNER_INFO *si;
2697 STACK_OF(X509_ATTRIBUTE) *attributes;
2698 - X509 *signer = NULL;
2699 + X509 *signercert = NULL;
2700 + EVP_PKEY *signerkey = NULL;
2702 /* Create a new sender nonce for all messages
2703 * XXXXXXXXXXXXXX should it be per transaction? */
2705 s->request_type_str = SCEP_REQUEST_PKCSREQ_STR;
2708 - signer = s->selfsigned;
2709 + signercert = s->signercert;
2710 + signerkey = s->signerkey;
2712 /* Create inner PKCS#7 */
2715 s->request_type_str = SCEP_REQUEST_GETCERTINIT_STR;
2718 - signer = s->selfsigned;
2719 + signercert = s->signercert;
2720 + signerkey = s->signerkey;
2722 /* Create inner PKCS#7 */
2725 s->request_type_str = SCEP_REQUEST_GETCERT_STR;
2728 - signer = localcert;
2729 + signercert = localcert;
2732 /* Read data in memory bio */
2733 databio = BIO_new(BIO_s_mem());
2735 s->request_type_str = SCEP_REQUEST_GETCRL_STR;
2738 - signer = localcert;
2739 + signercert = localcert;
2742 /* Read data in memory bio */
2743 databio = BIO_new(BIO_s_mem());
2747 /* Add signer certificate and signature */
2748 - PKCS7_add_certificate(s->request_p7, signer);
2749 + PKCS7_add_certificate(s->request_p7, signercert);
2750 if ((si = PKCS7_add_signature(s->request_p7,
2751 - signer, rsa, sig_alg)) == NULL) {
2752 + signercert, signerkey, sig_alg)) == NULL) {
2753 fprintf(stderr, "%s: error adding PKCS#7 signature\n", pname);
2754 ERR_print_errors_fp(stderr);
2755 exit (SCEP_PKISTATUS_P7);
2757 STACK_OF(X509_ATTRIBUTE) *attribs;
2759 unsigned char buffer[1024];
2761 + X509 *recipientcert;
2762 + EVP_PKEY *recipientkey;
2764 /* Create new memory BIO for outer PKCS#7 */
2765 memorybio = BIO_new(BIO_s_mem());
2766 @@ -547,10 +553,14 @@
2768 /* Decrypt the inner PKCS#7 */
2769 if ((s->request_type == SCEP_REQUEST_PKCSREQ) ||
2770 - (s->request_type == SCEP_REQUEST_GETCERTINIT))
2771 - recipient = s->selfsigned;
2773 - recipient = localcert;
2774 + (s->request_type == SCEP_REQUEST_GETCERTINIT)) {
2775 + recipientcert = s->signercert;
2776 + recipientkey = s->signerkey;
2779 + recipientcert = localcert;
2780 + recipientkey = rsa;
2783 printf("%s: reading inner PKCS#7\n",pname);
2784 p7enc = d2i_PKCS7_bio(outbio, NULL);
2786 outbio = BIO_new(BIO_s_mem());
2788 printf("%s: decrypting inner PKCS#7\n",pname);
2789 - if (PKCS7_decrypt(p7enc, rsa, recipient, outbio, 0) == 0) {
2790 + if (PKCS7_decrypt(p7enc, recipientkey, recipientcert, outbio, 0) == 0) {
2791 fprintf(stderr, "%s: error decrypting inner PKCS#7\n", pname);
2792 ERR_print_errors_fp(stderr);
2793 exit (SCEP_PKISTATUS_P7);
2794 diff -uN sscep/sceputils.c sscep-ng2/sceputils.c
2795 --- sscep/sceputils.c 2003-02-09 14:18:23.000000000 +0100
2796 +++ sscep-ng2/sceputils.c 2006-04-25 16:27:03.000000000 +0200
2800 /* Copy the pointer and return */
2801 - s->selfsigned = cert;
2802 + s->signercert = cert;
2803 + s->signerkey = rsa;
2807 diff -uN sscep/sscep.c sscep-ng2/sscep.c
2808 --- sscep/sscep.c 2003-04-17 07:47:04.000000000 +0200
2809 +++ sscep-ng2/sscep.c 2006-04-28 11:06:16.000000000 +0200
2812 /* Skip first parameter and parse the rest of the command */
2814 - while ((c = getopt(argc, argv, "c:de:E:f:F:i:k:l:L:n:p:r:Rs:S:t:T:u:vw:")) != -1)
2815 + 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)
2840 n_num = atoi(optarg);
2853 + printf("argv: %s\n", argv[optind]);
2857 @@ -402,15 +414,38 @@
2858 case SCEP_OPERATION_GETCERT:
2859 case SCEP_OPERATION_GETCRL:
2860 /* Read local certificate */
2861 - read_local_cert();
2863 + fprintf(stderr, "%s: missing local cert (-l)\n", pname);
2864 + exit (SCEP_PKISTATUS_FILE);
2866 + read_cert(&localcert, l_char);
2868 case SCEP_OPERATION_ENROLL:
2870 * Read in CA cert, private key and certificate
2871 * request in global variables.
2878 + fprintf(stderr, "%s: missing private key (-k)\n", pname);
2879 + exit (SCEP_PKISTATUS_FILE);
2881 + read_key(&rsa, k_char);
2883 + if ((K_flag && !O_flag) || (!K_flag && O_flag)) {
2884 + fprintf(stderr, "%s: -O also requires -K (and vice-versa)\n", pname);
2885 + exit (SCEP_PKISTATUS_FILE);
2889 + read_key(&renewal_key, K_char);
2893 + read_cert(&renewal_cert, O_char);
2896 if (operation_flag == SCEP_OPERATION_ENROLL)
2899 @@ -426,7 +461,14 @@
2901 fprintf(stdout, "%s: generating selfsigned "
2902 "certificate\n", pname);
2903 - new_selfsigned(&scep_t);
2906 + new_selfsigned(&scep_t);
2908 + /* Use existing certificate */
2909 + scep_t.signercert = renewal_cert;
2910 + scep_t.signerkey = renewal_key;
2913 /* Write the selfsigned certificate if requested */
2916 "file for writing\n", pname);
2917 exit (SCEP_PKISTATUS_ERROR);
2919 - if (PEM_write_X509(fp,scep_t.selfsigned) != 1) {
2920 + if (PEM_write_X509(fp,scep_t.signercert) != 1) {
2921 fprintf(stderr, "%s: error while "
2922 "writing certificate file\n", pname);
2923 ERR_print_errors_fp(stderr);
2928 - fprintf(stdout, "\nsscep version %s\n\n" , VERSION);
2929 + fprintf(stdout, "\nsscep version %s using %s\n\n" ,
2930 + VERSION,SSLeay_version(SSLEAY_VERSION));
2931 fprintf(stdout, "Usage: %s OPERATION [OPTIONS]\n"
2932 "\nAvailable OPERATIONs are\n"
2933 " getca Get CA/RA certificate(s)\n"
2935 "\nOPTIONS for OPERATION enroll are\n"
2936 " -k <file> Private key file\n"
2937 " -r <file> Certificate request file\n"
2938 + " -K <file> Signature private key file, use with -O\n"
2939 + " -O <file> Signature certificate (used instead of self-signed)\n"
2940 " -l <file> Write enrolled certificate in file\n"
2941 " -e <file> Use different CA cert for encryption\n"
2942 " -L <file> Write selfsigned certificate in file\n"
2944 " -T <secs> Max polling time in seconds\n"
2945 " -n <count> Max number of GetCertInitial requests\n"
2946 " -R Resume interrupted enrollment\n"
2947 + " -C Check subject DN in the certificate return by the\n"
2948 + " CA (default is to match on the public key only)\n"
2949 "\nOPTIONS for OPERATION getcert are\n"
2950 " -k <file> Private key file\n"
2951 " -l <file> Local certificate file\n"
2952 diff -uN sscep/sscep.h sscep-ng2/sscep.h
2953 --- sscep/sscep.h 2003-04-17 07:50:04.000000000 +0200
2954 +++ sscep-ng2/sscep.h 2006-04-28 10:46:49.000000000 +0200
2956 #include <openssl/objects.h>
2957 #include <openssl/asn1_mac.h>
2960 /* Global defines */
2962 -#define VERSION "20030417"
2963 +#define VERSION "20060428"
2965 /* SCEP operations */
2967 @@ -128,13 +127,13 @@
2971 +X509 *renewal_cert;
2974 +EVP_PKEY *renewal_key;
2984 int recipient_nonce_len;
2989 + EVP_PKEY *signerkey;
2994 @@ -251,13 +252,13 @@
2995 int init_scep(void);
2997 /* Read RSA private key file */
2998 -void read_key(void);
2999 +void read_key(EVP_PKEY** key, char* filename);
3001 /* Read CA certificate file */
3002 void read_ca_cert(void);
3004 /* Read local certificate file */
3005 -void read_local_cert(void);
3006 +void read_cert(X509** cert, char* filename);
3008 /* Read certificate request and private key */
3009 void read_request(void);
projects / openwrt / svn-archive / archive.git / blob