net/sscep/patches/001-certnanny.patch

   1 This patch adds support for signing requests with an existing key.
   2 It was taken from CertNanny <http://www.cynops.de/oss/CertNanny/>
   3
   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
   7 @@ -7,13 +7,14 @@
   8
   9  CC     = gcc
  10  CFLAGS = -Wall -O
  11 +LDLIBS = -lcrypto
  12
  13  MAN    = sscep.8
  14  PROG   = sscep
  15  OBJS    = sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o
  16
  17  $(PROG): $(OBJS)
  18 -       $(CC) $(CFLAGS) -lcrypto -o $(PROG) $(OBJS)
  19 +       $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o $(PROG) $(OBJS) $(LDLIBS)
  20
  21  clean:
  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
  26 @@ -51,11 +51,13 @@
  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)****
  31
  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
  35 -
  36 +(****) automatic approval according to newer SCEP drafts requires
  37 +       OpenCA 0.9.2.4 or higher
  38
  39  HOW TO COMPILE
  40  ==============
  41 @@ -76,7 +78,7 @@
  42
  43  $ ./sscep
  44
  45 -sscep version 20030131
  46 +sscep version 2005XXXX
  47
  48  Usage: ./sscep OPERATION [OPTIONS]
  49
  50 @@ -103,6 +105,8 @@
  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
  59 @@ -152,6 +156,16 @@
  60  CAIdentifier   Some CAs require you to define this. Example: mydomain.com
  61                 Command line option: -i
  62
  63 +CheckSubjectName
  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
  69 +               and DC).
  70 +               Example: yes
  71 +               Command line option: -C
  72 +
  73  CertReqFile    Certificate request file created with mkrequest.
  74                 Example: ./local.csr
  75                 Command line option: -r
  76 @@ -171,6 +185,21 @@
  77                 the signature. Example: ./enc.crt
  78                 Command line option: -e
  79
  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).
  88 +               Example: ./sig.crt
  89 +               Command line option: -O
  90 +
  91 +SignKeyFile    See SignCertFile. Specifies the corresponding private key.
  92 +               Example: ./sig.key
  93 +               Command line option: -K
  94 +
  95  FingerPrint    Display fingerprint algorithm. Available algorithms are md5
  96                 and sha1. Default is md5.
  97                 Command line option: -F
  98 @@ -367,6 +396,23 @@
  99  the challenge password), it returns SUCCESS as a first reply. Otherwise, the
 100  enrollment requires manual signing and authentication (perhaps a phone call).
 101
 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
 106 +key pair).
 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).
 114 +
 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.
 118 +
 119
 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
 125 @@ -16,6 +16,9 @@
 126  int c_flag;
 127  char *c_char;
 128
 129 +/* Check subject DN */
 130 +int C_flag;
 131 +
 132  /* Debug? */
 133  int d_flag;
 134
 135 @@ -51,10 +54,18 @@
 136  char *k_char;
 137  int k_flag;
 138
 139 +/* Private key of already existing certificate */
 140 +char *K_char;
 141 +int K_flag;
 142 +
 143  /* Request count */
 144  int n_flag;
 145  int n_num;
 146
 147 +/* Already existing certificate (to be renewed) */
 148 +char *O_char;
 149 +int O_flag;
 150 +
 151  /* Proxy */
 152  char *p_char;
 153  int p_flag;
 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
 157 @@ -0,0 +1,2367 @@
 158 +
 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
 163 +                                                         Cisco Systems
 164 +
 165 +Category: Informational                                  11 Feb 2005
 166 +
 167 +
 168 +Cisco Systems' Simple Certificate Enrollment Protocol(SCEP):
 169 +
 170 +Status of this Memo
 171 +
 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
 175 +
 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.
 179 +
 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."
 184 +
 185 +The list of current Internet-Drafts can be accessed at
 186 +http://www.ietf.org/ietf/1id-abstracts.txt
 187 +
 188 +The list of Internet-Draft Shadow Directories can be accessed at
 189 +http://www.ietf.org/shadow.html.
 190 +
 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.
 194 +
 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
 198 +with RFC 3668.
 199 +
 200 +Abstract
 201 +
 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.
 207 +
 208 +
 209 +Table of Contents
 210 +
 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
 220 +
 221 +\fLiu/Madson/McGrew/Nourse                                      [Page 2]
 222 +
 223 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 224 +
 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
 246 +
 247 +Section 1. Introduction
 248 +
 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.
 257 +
 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
 264 +each operation.
 265 +
 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.
 272 +
 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.
 277 +
 278 +\fLiu/Madson/McGrew/Nourse                                      [Page 3]
 279 +
 280 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 281 +
 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:
 286 +
 287 +  CA and RA public key distribution
 288 +  Certificate enrollment
 289 +  Certificate revocation
 290 +  Certificate query
 291 +  CRL query
 292 +
 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.
 302 +
 303 +2.1 SCEP Entity types
 304 +
 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.
 309 +
 310 +2.1.1 Requesters
 311 +
 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:
 316 +
 317 +  Fully qualified domain name, for example, router.cisco.com
 318 + IP address,  Serial number, and/or x.500 distinguished name
 319 +
 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.
 329 +
 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.
 334 +
 335 +
 336 +\fLiu/Madson/McGrew/Nourse                                      [Page 4]
 337 +
 338 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 339 +
 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.
 347 +
 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
 350 +enrollment request.
 351 +
 352 +2.1.1.1  Local Key/Certificate/CRL Storage and Certificate-name uniqueness
 353 +
 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.
 368 +
 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.
 381 +
 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.
 388 +
 389 +2.1.1.2 Requester authentication
 390 +
 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]
 395 +
 396 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 397 +
 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
 426 +DES encryption.
 427 +
 428 +2.1.1.3  Requester Uses Existing CA-Issued or Self-Signed Certificates
 429 +
 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]
 453 +
 454 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 455 +
 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.
 461 +
 462 +2.1.1.4 Trusted CA Store
 463 +
 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.
 470 +
 471 +2.1.2 Certificate Authority
 472 +
 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.
 487 +
 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.
 493 +
 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.
 497 +
 498 +The updating of the CA's public key is addressed in Appendix G.
 499 +
 500 +2.1.3 Registration Authorities
 501 +
 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).
 506 +
 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
 512 +
 513 +In this section, we give a high level overview of the PKI operations as
 514 +defined in SCEP.
 515 +
 516 +2.2.1 Requester Initialization
 517 +
 518 +The requester initialization includes the key pair generation and the
 519 +configuring of the required information to communicate with the
 520 +certificate authority.
 521 +
 522 +2.2.1.1  Key Pairs
 523 +
 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).
 527 +
 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.
 531 +
 532 +2.2.1.2 Required Information
 533 +
 534 +A requester is required to have the following information configured
 535 +before starting any PKI operations:
 536 +
 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.
 546 +
 547 +
 548 +2.2.2  CA/RA Certificate Distribution
 549 +
 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
 552 +
 553 +\fLiu/Madson/McGrew/Nourse                                      [Page 8]
 554 +
 555 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 556 +
 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.
 564 +
 565 +This operation is defined as a transaction consisting of one HTTP Get
 566 +message and one HTTP Response message:
 567 +
 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
 574 +     call CA operator.
 575 +                                    Receive call and check finger print
 576 +
 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.
 581 +
 582 +
 583 +2.2.3 Certificate Enrollment
 584 +
 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.
 598 +
 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.
 609 +
 610 +\fLiu/Madson/McGrew/Nourse                                      [Page 9]
 611 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 612 +
 613 +
 614 +The transaction in automatic mode:
 615 +
 616 +         REQUESTER                           CA SERVER
 617 +
 618 +PKCSReq: PKI cert. enrollment msg
 619 +     --------------------------------> CertRep: pkiStatus = SUCCESS
 620 +                                      certificate attached
 621 +                                       <------------------------------
 622 +     Receive issued certificate.
 623 +
 624 +The transaction in manual mode:
 625 +
 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................
 634 +
 635 +     GetCertInitial: polling msg
 636 +     --------------------------------> CertRep: pkiStatus = SUCCESS
 637 +                                      certificate attached
 638 +                                       <------------------------------
 639 +     Receive issued certificate.
 640 +
 641 +2.2.4 Requester Certificate Revocation
 642 +
 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.
 650 +
 651 +2.2.5 Certificate  Access
 652 +
 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)
 658 +are used as filter.
 659 +
 660 +For the environment where LDAP is not available, a certificate query
 661 +message is defined to retrieve the certificates from the CA.
 662 +
 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
 666 +
 667 +\fLiu/Madson/McGrew/Nourse                                      [Page 10]
 668 +
 669 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 670 +
 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:
 674 +
 675 +         REQUESTER                           CA SERVER
 676 +     GetCert: PKI cert query msg
 677 +     -------------------------------> CertRep:  pkiStatus = SUCCESS
 678 +                                     certificate
 679 +attached
 680 +                                      <-----------------------------
 681 +     Receive the certificate.
 682 +
 683 +2.2.6 CRL Distribution
 684 +
 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.
 687 +
 688 +There are three methods to query CRL.
 689 +
 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
 694 +versions.
 695 +
 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.
 700 +
 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.
 707 +
 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.
 711 +
 712 +         REQUESTER                           CA SERVER
 713 +     GetCRL: PKI CRL query msg
 714 +     ----------------------------------> CertRep:  CRL attached
 715 +                                       <--------------------------------
 716 +
 717 +2.3  PKI Operation Transactional Behavior
 718 +
 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
 722 +
 723 +
 724 +\fLiu/Madson/McGrew/Nourse                                      [Page 11]
 725 +
 726 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 727 +
 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
 733 +be defined first.
 734 +
 735 +2.3.1 Transaction Identifier
 736 +
 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.
 751 +
 752 +2.3.2 State Transitions in Certificate Enrollment
 753 +
 754 +The requester state transitions during enrollment operation are
 755 +indicated in the diagram below:
 756 +                                    +-<------+
 757 +                                    |        |
 758 +                                   GetCertInitial triggered by timeout or
 759 +                                    |        |    manual authentication
 760 +                                    |        |
 761 +     [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED]
 762 +           |           PKCSReq          |        CertRep with SUCCESS
 763 +           |                            |
 764 +           |                            |
 765 +           +--------<-------------------+
 766 +           request rejected, timeout, or error
 767 +
 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
 775 +exceeded.
 776 +
 777 +If an error or timeout occurs in the CERT-REQ-PENDING state, the end
 778 +entity will transition to the CERT-NONEXISTANT state.
 779 +
 780 +
 781 +\fLiu/Madson/McGrew/Nourse                                      [Page 12]
 782 +
 783 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 784 +
 785 +
 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.
 792 +
 793 +
 794 +2.3.3 Transaction Behavior of Certificate/CRL Access
 795 +
 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.
 802 +
 803 +2.4 Security
 804 +
 805 +The security goals of SCEP are that no adversary can:
 806 +
 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
 811 +  probability.
 812 +
 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.
 820 +[See Appendix F].
 821 +
 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.
 831 +
 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
 838 +
 839 +\fLiu/Madson/McGrew/Nourse                                      [Page 13]
 840 +
 841 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 842 +
 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
 847 +service attacks.
 848 +
 849 +Section 3 Transport Protocol
 850 +
 851 +In the SCEP protocol, HTTP is used as the transport protocol for the PKI
 852 +messages.
 853 +
 854 +3.1 HTTP "GET" and "POST" Message Format
 855 +
 856 +The following is the syntax definition of a HTTP GET message sent from
 857 +a requester to a certificate authority server:
 858 +
 859 +Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE
 860 +where:
 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).
 872 +
 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.
 877 +
 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.
 882 +
 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.
 888 +
 889 +For example. a requester may submit a message via HTTP to the server
 890 +as follows:
 891 +
 892 +GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
 893 +QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA==
 894 +\fLiu/Madson/McGrew/Nourse                                      [Page 13a]
 895 +
 896 +If supported by the CA, the message may also be sent via HTTP POST:
 897 +
 898 +POST /cgi-bin/pkiclient.exe?operation=PKIOperation
 899 +
 900 +This is further described in Appendix H.
 901 +To determine if the CA supports POST, use the GetCACaps message described
 902 +in Appendix F.
 903 +
 904 +
 905 +3.2 Response Message Format
 906 +
 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:
 912 +
 913 +"Content-Type:application/x-pki-message\n\n"<BER-encoded PKI msg>
 914 +
 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:
 921 +
 922 +"Content-Type:application/x-x509-ca-cert\n\n"<BER-encoded X509>
 923 +
 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.
 929 +
 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.
 934 +
 935 +If the CA supports it, PKIOperation may also be done via an HTTP POST.
 936 +This is described in Appendix H.
 937 +
 938 +\fLiu/Madson/McGrew/Nourse                                      [Page 14]
 939 +
 940 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 941 +
 942 +Section 4  Secure Transportation: PKCS#7
 943 +
 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.
 949 +
 950 +4.1 SCEP Message Format
 951 +
 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
 959 +attributes.
 960 +
 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.
 968 +
 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.
 974 +
 975 +\fLiu/Madson/McGrew/Nourse                                      [Page 15]
 976 +
 977 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
 978 +
 979 +  pkiMessage ContentInfo ::= {
 980 +      contentType {pkcs-7 signedData(2)}
 981 +      content pkcsPKISigned
 982 +  }
 983 +  pkcsPKISigned SignedData ::= {
 984 +      version 1
 985 +      digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549)
 986 +                        digestAlgorithm(2) 5}
 987 +      contentInfo {
 988 +          contentType {pkcs-7 1} --  data content identifier
 989 +          content pkcsPKIEnvelope -- enveloped information portion
 990 +      }
 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
 995 +  }
 996 +  pkcsPKIEnveloped EnvelopedData ::= {
 997 +      version 0
 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
1003 +      }
1004 +  }
1005 +
1006 +4.2 Signed Transaction Attributes
1007 +
1008 +The following transaction attributes are encoded as authenticated
1009 +attributes.  Please refer to Appendix B for the OID definitions.
1010 +
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
1017 +
1018 +where:
1019 +
1020 +  The transactionID is an attribute which uniquely identify a
1021 +  transaction.  This attribute is required in all PKI messages.
1022 +
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:
1026 +
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
1032 +
1033 +\fLiu/Madson/McGrew/Nourse                                      [Page 16]
1034 +
1035 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1036 +
1037 +
1038 +  All response message will include transaction status information which
1039 +  is defined as pkiStatus attribute:
1040 +
1041 +          SUCCESS (0)   -- request granted
1042 +          FAILURE (2)   -- request rejected
1043 +          PENDING (3)   -- request pending for manual approval.
1044 +
1045 +  If the status in the response is FAILURE, the failinfo attribute will
1046 +  contain one of the following failure reasons:
1047 +
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
1055 +
1056 +  The attributes of senderNonce and recipientNonce are the 16 byte
1057 +  random numbers generated for each transaction to prevent the replay
1058 +  attack.
1059 +
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.
1068 +
1069 +Section 5. SCEP Transaction Specification
1070 +
1071 +In this section each SCEP transaction is specified in terms of the
1072 +complete messages exchanged during the transaction.
1073 +
1074 +5.1 Certificate Enrollment
1075 +
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
1088 +
1089 +
1090 +\fLiu/Madson/McGrew/Nourse                                      [Page 17]
1091 +
1092 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1093 +
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.
1097 +
1098 +Precondition:
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.
1102 +
1103 +Postcondition:
1104 +  Either the certificate is received by the requester, or the end
1105 +  entity is notified to do the manual authentication, or the request
1106 +  is rejected.
1107 +
1108 +5.1.1 PKCSReq Message Format
1109 +
1110 +A PKCSReq message is created by following the steps defined below:
1111 +
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.
1116 +
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
1121 +    request.
1122 +
1123 +3.  Generate a unique string as the transaction id.
1124 +
1125 +4.  Generate a 16 byte random number as senderNonce.
1126 +
1127 +5.  Generate message digest on the enveloped PKCS#10 certificate request
1128 +    using the selected digest algorithm.
1129 +
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.
1135 +
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.
1139 +
1140 +In the following, the PKCSReq message is defined following the ASN.1
1141 +notation.
1142 +
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
1145 +is known.
1146 +
1147 +
1148 +\fLiu/Madson/McGrew/Nourse                                      [Page 18]
1149 +
1150 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1151 +
1152 +  -- PKCSReq information portion
1153 +  pkcsCertReq CertificationRequest ::= {   -- PKCS#10
1154 +      version 0
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"
1159 +      }
1160 +      attributes {
1161 +          challengePassword {{pkcs-9 7} "password string" }
1162 +          extensions
1163 +      }
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."
1169 +  }
1170 +  -- Enveloped information portion
1171 +  pkcsCertReqEnvelope EnvelopeData ::= {   -- PKCS#7
1172 +      version 0
1173 +      recipientInfo {
1174 +          version 0
1175 +          issuerAndSerialNumber {
1176 +              issuer  "the CA issuer name"
1177 +              serialNumber  "the CA certificate serial number"
1178 +          }
1179 +          keyEncryptionAlgorithm  {pkcs-1 1}  -- rsa encryption
1180 +          encryptedKey "content-encryption key
1181 +                        encrypted by CA public key"
1182 +      }
1183 +      encryptedContentInfo {
1184 +          contentType {pkcs-7 1}  -- data content
1185 +          contentEncryptionAlgorithm  "object identifier
1186 +                                       for DES encryption"
1187 +          encryptedContent  "encrypted pkcsCertReq using the content-
1188 +                             encryption key"
1189 +      }
1190 +  }
1191 +  -- Signed PKCSReq
1192 +  pkcsCertReqSigned SignedData ::= { -- PKCS#7
1193 +      version 1
1194 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1195 +                       digestAlgorithm(2) 5}
1196 +      contentInfo {
1197 +          contentType {pkcs-7 1} -- data content identifier
1198 +          content  pkcsCertReqEnvelope
1199 +      }
1200 +     certificate {   -- requester self-signed or CA-issued certificate
1201 +          version 3
1202 +          serialNumber  "the transaction id associated with enrollment"
1203 +          signature {pkcs-1 4}  -- md5WithRSAEncryption
1204 +
1205 +
1206 +\fLiu/Madson/McGrew/Nourse                                      [Page 19]
1207 +
1208 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1209 +
1210 +     issuer " the requester's subject name"
1211 +          validity {
1212 +              notBefore "a UTC time"
1213 +              notAfter  "a UTC time"
1214 +          }
1215 +          subject  "the requester's subject name"
1216 +          subjectPublicKeyInfo {
1217 +              algorithm {pkcs-1 1}
1218 +              subjectPublicKey "DER encoding of requester's public key"
1219 +          }
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."
1224 +      }
1225 +      signerInfo  {
1226 +          version 1
1227 +          issuerAndSerialNumber {
1228 +              issuer "the requester's subject name"
1229 +              serialNumber "the transaction id associated
1230 +                            with the enrollment"
1231 +          }
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
1238 +                                                          string"}
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"}
1246 +          }
1247 +          digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption
1248 +          encryptedDigest "encrypted digest of the authenticated
1249 +                           attributes using requester's private key"
1250 +      }
1251 +  }
1252 +  pkcsReq PKIMessage ::= {
1253 +      contentType {pkcs-7 2}
1254 +      content pkcsCertRepSigned
1255 +  }
1256 +
1257 +
1258 +
1259 +
1260 +
1261 +
1262 +
1263 +
1264 +\fLiu/Madson/McGrew/Nourse                                      [Page 20]
1265 +
1266 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1267 +
1268 +5.1.2 CertRep Message Format
1269 +
1270 +The response to an SCEP enrollment request is a CertRep message.
1271 +
1272 +5.1.2.1 PENDING Response
1273 +
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.
1278 +
1279 +CertRepSigned  SignedData ::= { -- PKCS#7
1280 +    version 1
1281 +    digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1282 +                     digestAlgorithm(2) 5}
1283 +    contentInfo {contentType {pkcs-7 1}  -- empty content
1284 +    }
1285 +    signerInfo {
1286 +        version 1
1287 +        issuerAndSerialNumber {
1288 +           issuer "name of CA that issued the CA [RA] cert"
1289 +           serialNumber "the serial number of the CA [RA] cert"
1290 +        }
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>}
1302 +        }
1303 +        digestEncrytionAlgorithm {pkcs-1 1}
1304 +        encryptedDigest  "encrypted message digest of the authenticated
1305 +                         attributes using the CA's [RA's] private key"
1306 +     }
1307 +}
1308 +CertRep PKIMessage ::= {
1309 +    contentType {pkcs-7 2}
1310 +    content CertRepSigned
1311 +}
1312 +
1313 +5.1.2.2 Failure Response
1314 +
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:
1318 +
1319 +    pkistatus {{id-attributes pkiStatus(3)} "FAILURE"}
1320 +    failInfo {{id-attributes failInfo(4)} "the reason to reject"}
1321 +
1322 +\fLiu/Madson/McGrew/Nourse                                      [Page 21]
1323 +
1324 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1325 +
1326 +5.1.2.3  SUCCESS response
1327 +
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:
1331 +
1332 +pkcsCertRep SignedData ::= { -- PKCS#7
1333 +    version 1
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}
1338 +    }
1339 +    certificates {
1340 +        certificate { -- issued requester's certificate  // must be first
1341 +            version 3
1342 +            serialNumber "issued requester's certificate serial number"
1343 +            signature {pkcs-1 4}  -- md5WithRSAEncryption
1344 +            issuer "the certificate authority issuer name"
1345 +            validity {
1346 +                notBefore "UTC time"
1347 +                notAfter "UTC time"
1348 +            }
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"
1354 +            }
1355 +            extensions  " the extensions as given in PKCS#10"
1356 +            signatureAlgorithm {pkcs-1 4}
1357 +            signature " the certificate authority signature"
1358 +        }
1359 +        certificate "the certificate authority certificate" (optional)
1360 +        certificate "the registration authority certificate(s)" (optional)
1361 +    }
1362 +}
1363 +pkcsCertRepEnvelope EnvelopedData ::= {  -- PKCS#7
1364 +    version 0
1365 +    recipientInfo {
1366 +        version 0
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"
1373 +        }
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"
1378 +    }
1379 +
1380 +
1381 +\fLiu/Madson/McGrew/Nourse                                      [Page 22]
1382 +
1383 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1384 +
1385 +    encryptedContentInfo {
1386 +        contentType {pkcs-7 1}  -- data content identifier
1387 +        contentEncryptionAlgorithm "OID for DES encryption"
1388 +        encryptedContent "encrypted pkcsCertRep using content encryption
1389 +                          key"
1390 +    }
1391 +}
1392 +pkcsCertRepSigned SignedData ::= { -- PKCS#7
1393 +    version 1
1394 +    digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1395 +                     digestAlgorithm(2) 5}
1396 +    contentInfo {
1397 +        contentType {pkcs-7 1}
1398 +        content pkcsCertRepEnvelope
1399 +    }
1400 +    signerInfo {
1401 +        version 1
1402 +        issuerAndSerialNumber {
1403 +            issuer "the certificate authority issuer name"
1404 +            serialNumber "the CA certificate's serial number"
1405 +        }
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
1413 +                                                        string"}
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>}
1418 +        }
1419 +        digestEncryptionAlgorithm {pkcs-1 1}
1420 +        encryptedDigest "encrypted digest of authenticate attributes
1421 +                         using CA's private key "
1422 +    }
1423 +}
1424 +CertRep PKIMessage ::= {
1425 +    contentType {pkcs-7 2}
1426 +    content pkcsCertRepSigned
1427 +}
1428 +
1429 +5.2 Poll for Requester Initial Certificate
1430 +
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.
1437 +
1438 +
1439 +\fLiu/Madson/McGrew/Nourse                                      [Page 23]
1440 +
1441 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1442 +
1443 +
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.
1447 +
1448 +PreCondition
1449 +    Either the requester has received a CertRep with pkiStatus set to be
1450 +    PENDING, or the previous PKCSReq has timed out.
1451 +
1452 +PostContition
1453 +    The requester has either received the certificate, or be rejected of
1454 +    its request, or the polling period ended as a failure.
1455 +
1456 +5.2.1 GetCertInitial Message Format
1457 +
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.
1461 +
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).
1465 +
1466 +-- Information portion
1467 +
1468 +pkcsGetCertInitial issuerAndSubject ::= {
1469 +    issuer "the certificate authority issuer name"
1470 +    subject "the requester subject name as given in PKCS#10"
1471 +}
1472 +pkcsGetCertInitialEnvelope EnvelopedData ::= {
1473 +    version 0
1474 +    recipientInfo {
1475 +        version 0
1476 +        issuerAndSerialNumber {
1477 +            issuer  "the CA issuer name"
1478 +            serialNumber "the CA certificate serial number"
1479 +        }
1480 +        keyEncryptionAlgorithm {pkcs-1 1}
1481 +        encryptedKey "content-encrypt key encrypted by CA's public key"
1482 +    }
1483 +    encryptedContentInfo {
1484 +        contentType {pkcs-7 1}  -- data content
1485 +        contentEncryptionAlgorithm "OID for DES encryption"
1486 +        encryptedContent "encrypted getCertInital"
1487 +    }
1488 +}
1489 +pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7
1490 +    version 1
1491 +    digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1492 +                     digestAlgorithm(2) 5}
1493 +    contentInfo {
1494 +        contentType {pkcs-7 1}
1495 +
1496 +
1497 +\fLiu/Madson/McGrew/Nourse                                      [Page 24]
1498 +
1499 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1500 +
1501 +        content pkcsGetCertIntialEnvelope
1502 +    }
1503 +     certificate {   -- the requester's self-signed certificate
1504 +         version 3
1505 +         serialNumber  "the transaction id associated with enrollment"
1506 +         signature {pkcs-1 4}  -- md5WithRSAEncryption
1507 +         issuer " the requester's subject name"
1508 +         validity {
1509 +             notBefore "a UTC time"
1510 +             notAfter  "a UTC time"
1511 +         }
1512 +         subject  "the requester's subject name"
1513 +         subjectPublicKeyInfo {
1514 +             algorithm {pkcs-1 1}
1515 +             subjectPublicKey "DER encoding of requester's public key"
1516 +         }
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."
1521 +     }
1522 +    signerInfo {
1523 +        version 1
1524 +        issuerAndSerialNumber {
1525 +            issuer "requester's subject name"
1526 +            serialNumber "the transaction id used in previous PKCSReq"
1527 +        }
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
1536 +                                                        string"}
1537 +                          -- same transaction idused in previous PKCSReq
1538 +            senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>}
1539 +        }
1540 +        digestEncryptionAlgorithm {pkcs-1 1}
1541 +        encryptedDigest "encrypted digest of authenticateAttributes"
1542 +    }
1543 +}
1544 +GetCertInitial PKIMessage ::= {
1545 +    contentType {pkcs-7 2}
1546 +    content pkcsGetCertInitialSigned
1547 +}
1548 +
1549 +
1550 +
1551 +5.2.2 GetCertInitial Response Message Format
1552 +
1553 +The response messages for GetCertInitial are the same as for PKCSReq.
1554 +
1555 +\fLiu/Madson/McGrew/Nourse                                      [Page 25]
1556 +
1557 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1558 +
1559 +5.3  Certificate Access
1560 +
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.
1570 +
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.
1573 +
1574 +PreCondition
1575 +   The queried certificate have been issued by the certificate authority
1576 +   and the issuer assigned serial number is known.
1577 +
1578 +PostCondition
1579 +    Either the certificate is sent back or the request is rejected.
1580 +
1581 +
1582 +5.3.1 GetCert Message Format
1583 +
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.
1591 +
1592 +  pkcsGetCert issuerAndSerialNumber ::= {
1593 +      issuer "the certificate issuer name"
1594 +      serialNumber "the certificate serial number"
1595 +  }
1596 +  pkcsGetCertEnvelope EnvelopedData ::= {
1597 +      version 0
1598 +      recipientInfo {
1599 +          version 0
1600 +          issuerAndSerialNumber {
1601 +              issuer  "the CA [RA] issuer name"
1602 +              serialNumber "the CA [RA] certificate serial number"
1603 +          }
1604 +          keyEncryptionAlgorithm {pkcs-1 1}
1605 +          encryptedKey "content-encrypt key encrypted
1606 +                        by CA [RA] public key"
1607 +      }
1608 +
1609 +
1610 +
1611 +
1612 +
1613 +\fLiu/Madson/McGrew/Nourse                                      [Page 26]
1614 +
1615 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1616 +
1617 +
1618 +      encryptedContentInfo {
1619 +          contentType {pkcs-7 1}  -- data content
1620 +          contentEncryptionAlgorithm "OID for DES encryption"
1621 +          encryptedContent "encrypted pkcsGetCert using the content
1622 +                            encryption key"
1623 +      }
1624 +  }
1625 +  pkcsGetCertSigned SignedData ::= {
1626 +      version 1
1627 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1628 +                       digestAlgorithm(2) 5}
1629 +      contentInfo {
1630 +          contentType {pkcs-7 1}
1631 +          content pkcsGetCertEnvelope
1632 +      }
1633 +      certificates {
1634 +          certificate "CA issued certificate"
1635 +                      or "self-signed certificate"
1636 +      }
1637 +      signerInfo {
1638 +          version 1
1639 +          issuerAndSerialNumber {
1640 +              issuer "the requester's subject name"
1641 +              serialNumber "requester's certificate serial number"
1642 +          }
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
1651 +                                                          string"}
1652 +              senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
1653 +          }
1654 +          digestEncryptionAlgorithm {pkcs-1 1}
1655 +          encryptedDigest "encrypted digest of authenticateAttributes"
1656 +      }
1657 +  }
1658 +  GetCert PKIMessage ::= {
1659 +      contentType {pkcs-7 2}
1660 +      content pkcsGetCertSigned
1661 +  }
1662 +
1663 +
1664 +
1665 +
1666 +
1667 +
1668 +
1669 +
1670 +
1671 +\fLiu/Madson/McGrew/Nourse                                      [Page 27]
1672 +
1673 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1674 +
1675 +
1676 +5.3.2 CertRep Message Format
1677 +
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.
1683 +
1684 +5.4  CRL Access
1685 +
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.
1693 +
1694 +PreCondition
1695 +    The certificate authority certificate has been downloaded to the end
1696 +    entity.
1697 +
1698 +PostCondition
1699 +    CRL sent back to the requester.
1700 +
1701 +5.4.1 GetCRL Message format
1702 +
1703 +The CRL is identified by using both CA's issuer name and the CA
1704 +certificate's serial number:
1705 +
1706 +  pkcsGetCRL issuerAndSerialNumber {
1707 +      issuer "the certificate authority issuer name"
1708 +      serialNumber "certificate authority certificate's serial number"
1709 +  }
1710 +
1711 +When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as
1712 +the following:
1713 +
1714 +  pkcsGetCRL SEQUENCE {
1715 +      crlIssuer  issuerAndSerialNumber
1716 +      distributionPoint CE-CRLDistPoints
1717 +  }
1718 +
1719 +where CE-CRLDisPoints is defined in X.509, but must contain only one
1720 +CRL distribution point.
1721 +
1722 +
1723 +
1724 +
1725 +
1726 +
1727 +
1728 +
1729 +
1730 +
1731 +\fLiu/Madson/McGrew/Nourse                                      [Page 28]
1732 +
1733 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1734 +
1735 +  pkcsGetCRLEnvelope EnvelopedData ::= {
1736 +      version 0
1737 +      recipientInfo {
1738 +          version 0
1739 +          issuerAndSerialNumber {
1740 +              issuer  "the certificate authority (or RA) issuer name"
1741 +              serialNumber "the CA (RA) certificate's serial number"
1742 +          }
1743 +          keyEncryptionAlgorithm {pkcs-1 1}
1744 +          encryptedKey "content-encrypt key encrypted by CA (RA) public key"
1745 +      }
1746 +      encryptedContentInfo {
1747 +          contentType {pkcs-7 1}  -- data content
1748 +          contentEncryptionAlgorithm "OID for DES encryption"
1749 +          encryptedContent "encrypted pkcsGetCRL"
1750 +      }
1751 +  }
1752 +  pkcsGetCRLSigned SignedData ::= {
1753 +      version 1
1754 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1755 +                       digestAlgorithm(2) 5}
1756 +      contentInfo {
1757 +          contentType {pkcs-7 1}
1758 +          content pkcsGetCRLEnvelope
1759 +      }
1760 +      certificates {
1761 +         certificate "CA-issued or self-signed requester's certificate"
1762 +      }
1763 +      signerInfo {
1764 +          version 1
1765 +          issuerAndSerialNumber {
1766 +              issuer "the requester's issuer name"
1767 +              serialNumber "the requester's certificate serial number"
1768 +          }
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
1777 +                                                          string"}
1778 +              senderNonce {{id-attribute senderNonce(3)} <16 bytes>}
1779 +          }
1780 +          digestEncryptionAlgorithm {pkcs-1 1}
1781 +          encryptedDigest "encrypted digest of authenticateAttributes"
1782 +      }
1783 +  }
1784 +  GetCRL PKIMessage ::= {
1785 +      contentType {pkcs-7 2}
1786 +      content pkcsGetCRLSigned
1787 +  }
1788 +
1789 +\fLiu/Madson/McGrew/Nourse                                      [Page 29]
1790 +
1791 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1792 +
1793 +
1794 +5.4.2  CertRep Message Format
1795 +
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.
1799 +
1800 +  pkcsCertRep SignedData ::= {
1801 +      version 1
1802 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1803 +                       digestAlgorithm(2) 5}
1804 +      contentInfo {
1805 +          contentType {pkcs-7 1}
1806 +      }
1807 +      crl {
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"
1816 +              ....
1817 +              -- last entry
1818 +              userCertificate "certificate serial number"
1819 +              revocationData "UTC time"
1820 +      }
1821 +  }
1822 +  pkcsCertRepEnvelope EnvelopedData ::= {
1823 +      version 0
1824 +      recipientInfo {
1825 +          version 0
1826 +          issuerAndSerialNumber {
1827 +              issuer  "the requester's issuer name"
1828 +              serialNumber "the requester certificate serial number"
1829 +          }
1830 +          keyEncryptionAlgorithm {pkcs-1 1}
1831 +          encryptedKey "content-encrypt key encrypted by requester's
1832 +                        public key "
1833 +      }
1834 +      encryptedContentInfo {
1835 +          contentType {pkcs-7 1}  -- data content
1836 +          contentEncryptionAlgorithm "OID for DES encryption"
1837 +          encryptedContent "encrypted pkcsCertRep using requester's
1838 +                            public key"
1839 +      }
1840 +  }
1841 +
1842 +
1843 +
1844 +
1845 +
1846 +
1847 +\fLiu/Madson/McGrew/Nourse                                      [Page 30]
1848 +
1849 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1850 +
1851 +
1852 +  pkcsCertRepSigned SignedData ::= { -- PKCS#7
1853 +      version 1
1854 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
1855 +                       digestAlgorithm(2) 5}
1856 +      contentInfo {
1857 +          contentType {pkcs-7 1}
1858 +          content pkcsCertRepEnvelope
1859 +      }
1860 +      signerInfo {
1861 +          version 1
1862 +          issuerAndSerialNumber {
1863 +              issuer "the certificate authority issuer name"
1864 +              serialNumber "the CA certificate's serial number"
1865 +          }
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
1874 +                                                          string"}
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>}
1879 +          }
1880 +          digestEncryptionAlgorithm {pkcs-1 1}
1881 +          encryptedDigest "encrypted digest of authenticatedAttributes
1882 +                           using CA private key"
1883 +      }
1884 +  }
1885 +
1886 +
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.
1890 +
1891 +This alternate encoding must be accepted wherever PKCS #7 Enveloped
1892 +Data is specified in this document.
1893 +
1894 +
1895 +
1896 +
1897 +
1898 +
1899 +
1900 +
1901 +
1902 +
1903 +
1904 +\fLiu/Madson/McGrew/Nourse                                      [Page 31]
1905 +
1906 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
1907 +
1908 +5.5 Get Certificate Authority Certificate
1909 +
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.
1927 +
1928 +5.5.1 GetCACert HTTP Message Format
1929 +   "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT
1930 +    where:
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.
1941 +
1942 +5.5.2 Response
1943 +
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.
1948 +
1949 +5.5.2.1 CA Certificate Only Response
1950 +
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.
1953 +
1954 +5.5.2.2 CA and RA Certificates Response
1955 +
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.
1961 +
1962 +\fLiu/Madson/McGrew/Nourse                                      [Page 32]
1963 +
1964 +5.5.3 Get Next Certificate Authority Certificate
1965 +
1966 +5.5.3.1 GetNextCACert HTTP Message Format
1967 +   "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT
1968 +
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.
1973 +
1974 +5.5.3.2 GetCACaps HTTP Message Format
1975 +   "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT
1976 +
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.
1981 +
1982 +5.6 Get Certificate Authority Certificate Chain
1983 +
1984 +GetCACertChain provides  a way to get the entire certificate chain.
1985 +
1986 +5.6.1 GetCACertChain HTTP Message Format
1987 +
1988 +   "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT
1989 +    where CGI-SCRIPT and CA-IDENT are as described for GetCACert.
1990 +
1991 +5.6.2 Response
1992 +
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.
1996 +
1997 +5.6.3 Backwards Compatability
1998 +
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.
2002 +
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.
2007 +
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.
2012 +
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.
2019 +
2020 +\fLiu/Madson/McGrew/Nourse                                      [Page 33]
2021 +
2022 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2023 +
2024 +The following is the ASN.1 definition of Cert-Only PKCS#7:
2025 +
2026 +  certOnly SignedData ::= {
2027 +      version 1
2028 +      digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549)
2029 +                       digestAlgorithm(2) 5}
2030 +
2031 +contentInfo {
2032 +          contentType {pkcs-7 1} -- data content identifier
2033 +          content  -- NULL
2034 +      }
2035 +      certificates   -- the RA and CA certificates.
2036 +  }
2037 +
2038 +  CARACerts PKIMessage ::= {  -- special pki message sent in the clear
2039 +      contentType {pkcs-7 2}
2040 +      content certOnly
2041 +  }
2042 +
2043 +
2044 +6.0 Security Considerations
2045 +
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.
2050 +
2051 +
2052 +7.0 Intellectual Property
2053 +
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.
2060 +
2061 +
2062 +8.0 References
2063 +
2064 +[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
2065 +1.5", RFC 2315, March 1998.
2066 +
2067 +[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version
2068 +1.5", RFC 2314, March 1998.
2069 +
2070 +[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key
2071 +Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
2072 +
2073 +
2074 +
2075 +
2076 +
2077 +
2078 +\fLiu/Madson/McGrew/Nourse                                      [Page 34]
2079 +
2080 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2081 +
2082 +Appendix A: Cisco Requester Subject Name Definition
2083 +
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.
2088 +
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.
2092 +
2093 +
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):
2096 +
2097 +    OU = InteropTesting, O = Entrust Technologies, C = CA
2098 +    RDN = {"alice.cisco.com", "172.21.114.67", "22334455"}
2099 +
2100 +
2101 +\fLiu/Madson/McGrew/Nourse                                      [Page 35]
2102 +
2103 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2104 +
2105 +Appendix B:  IPSEC Client Enrollment Certificate Request
2106 +
2107 +The following is the certificate enrollment request (PKCS#10) as created
2108 +by Cisco VPN Client:
2109 +
2110 +-----END NEW CERTIFICATE REQUEST-----
2111 +   0 30  439: SEQUENCE {
2112 +   4 30  288:   SEQUENCE {
2113 +   8 02    1:     INTEGER 0
2114 +  11 30   57:     SEQUENCE {
2115 +  13 31   55:       SET {
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
2120 +                           extn'
2121 +            :           }
2122 +            :         }
2123 +            :       }
2124 +  70 30  158:     SEQUENCE {
2125 +  73 30   13:       SEQUENCE {
2126 +  75 06    9:         OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1
2127 +                                                       1 1)
2128 +  86 05    0:         NULL
2129 +            :         }
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 ]
2140 +            :       }
2141 + 231 A0   63:     [0] {
2142 + 233 30   61:       SEQUENCE {
2143 + 235 06    9:         OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9
2144 +                                                      14)
2145 + 246 31   48:         SET {
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
2151 +
2152 +
2153 +\fLiu/Madson/McGrew/Nourse                                      [Page 36]
2154 +
2155 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2156 +
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
2159 +            :               }
2160 +            :             }
2161 +            :           }
2162 +            :         }
2163 +            :       }
2164 +            :     }
2165 +
2166 + 296 30   13:   SEQUENCE {
2167 + 298 06    9:     OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549
2168 +                                                          1 1 4)
2169 + 309 05    0:     NULL
2170 +            :     }
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
2180 +            :   }
2181 +
2182 +
2183 +Appendix C:   Private OID Definitions
2184 +
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.
2189 +
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)}
2200 +
2201 +
2202 +\fLiu/Madson/McGrew/Nourse                                      [Page 37]
2203 +
2204 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2205 +
2206 + Appendix D:   CRL Query by means of LDAP
2207 +
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.
2211 +
2212 +For example, the certificate issued by Entrust VPN contains
2213 +the following DN as the CRL distribution point:
2214 +
2215 +
2216 +
2217 +CN = CRL1, O = cisco, C = US.
2218 +
2219 + The asn.1 encoding of this distribution point is:
2220 +
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
2223 +     13 04 43 52 4C 31
2224 +
2225 +
2226 +The ldap form would be:
2227 +
2228 +ldap://servername/CN=CRL1,O=cisco,C=US
2229 +
2230 +
2231 +
2232 +Appendix E:  SCEP State Transitions
2233 +
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.
2237 +
2238 +
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.
2243 +
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.
2258 +
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.
2267 +
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
2270 +
2271 +
2272 +\fLiu/Madson/McGrew/Nourse                                      [Page 38]
2273 +
2274 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2275 +
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.
2279 +
2280 +The following gives several examples of client to CA transactions.
2281 +
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.
2286 +
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."
2292 +
2293 +Successful Enrollment Case: no manual authentication
2294 +PKCSReq (1)             ----------> CA Signs Cert
2295 +Client Installs Cert    <---------- CertRep (1) SIGNED CERT
2296 +
2297 +
2298 +
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
2310 +
2311 +
2312 +
2313 +Resync Case - CA Receive and Signs PKCSReq, Client Did not receive
2314 +CertRep:
2315 +
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
2322 +                                   CertRep(3)
2323 +(Time Out)
2324 +PKCSReq (3)           ----------> Cert already signed, sent back to
2325 +                                  client
2326 +Client Installs Cert  <---------- CertRep (3) SIGNED CERT
2327 +
2328 +
2329 +
2330 +\fLiu/Madson/McGrew/Nourse                                      [Page 39]
2331 +
2332 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2333 +
2334 +
2335 +Case when NVRAM is lost and client has to generate a new key pair, there
2336 +is no change of name information:
2337 +
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
2342 +                                  this DN.
2343 +Client Admin Revokes  <---------- CertRep (5) OVERLAPPING CERT ERROR
2344 +PKCSReq (5)           ----------> CA Signs Cert
2345 +Client Installs Cert  <---------- CertRep (5) SIGNED CERT
2346 +
2347 +
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
2357 +                                     ERROR
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
2363 +
2364 +
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
2376 +* Case 1
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
2381 +* Case 2
2382 +PKCSReq (13)          ----------> Cert has been signed
2383 +Client Installs Cert  <---------- CertRep (13) SIGNED CERT
2384 +
2385 +
2386 +
2387 +
2388 +\fLiu/Madson/McGrew/Nourse                                      [Page 40]
2389 +
2390 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2391 +
2392 +Appendix F. CA Capabilities
2393 +
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
2396 +are NOT sent):
2397 +
2398 +Keyword               Description
2399 +
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
2408 +                     certificate.
2409 +
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.
2412 +
2413 +Example:
2414 +
2415 +GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca
2416 +
2417 +returns:
2418 +
2419 +GetNextCACert
2420 +POSTPKIOperation
2421 +
2422 +This means that the CA supports the GetNextCACert message and allows
2423 +PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent
2424 +using HTTP POST.
2425 +
2426 +
2427 +\fLiu/Madson/McGrew/Nourse                                      [Page 41]
2428 +
2429 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2430 +
2431 +Appendix G. Certificate Renewal and CA Key Rollover
2432 +
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.
2435 +
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.
2438 +
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.
2441 +
2442 +
2443 +Example:
2444 +
2445 +GetNextCACert           ---------->
2446 +                       <---------- CertRep (3) New CA certificate
2447 +
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.
2452 +
2453 +
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.
2457 +
2458 +
2459 +\fLiu/Madson/McGrew/Nourse                                      [Page 42]
2460 +
2461 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2462 +
2463 +Appendix H. PKIOperation via HTTP POST Message
2464 +
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
2469 +used.
2470 +
2471 +POST /cgi-bin/pkiclient.exe?operation=PKIOperation
2472 +<binary PKCS7 data>
2473 +
2474 +The client can verify that the CA supports SCEP messages via POST by
2475 +looking for the "POSTPKIOperation" capability (See Appendix F).
2476 +
2477 +
2478 +
2479 +
2480 +
2481 +
2482 +\fLiu/Madson/McGrew/Nourse                                      [Page 43]
2483 +
2484 +Cisco Systems' Simple Certificate Enrollment Protocol          Feb 2005
2485 +
2486 +Appendix Y. Author Contact Information
2487 +
2488 +Xiaoyi Liu                     Cheryl Madson
2489 +Cisco                          Cisco
2490 +510 McCarthy Drive             510 McCarthy Drive
2491 +Milpitas, CA                   Milpitas, CA.
2492 +xliu@cisco.com                 cmadson@cisco.com
2493 +
2494 +
2495 +David McGrew                   Andrew Nourse
2496 +Cisco                          Cisco
2497 +170 West Tasman Drive          510 McCarthy Drive
2498 +San Jose, CA 94134             Milpitas, CA.
2499 +mcgrew@cisco.com               nourse@cisco.com
2500 +
2501 +
2502 +
2503 +
2504 +Appendix Z.  Copyright Section
2505 +
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.
2509 +
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.
2517 +
2518 +
2519 +
2520 +
2521 +This draft expires 11 Aug 2005
2522 +
2523 +[End of draft-nourse-scep-11.txt]
2524 +
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
2528 @@ -55,8 +55,11 @@
2529         PKCS7                   *p7;
2530         STACK_OF(X509)          *certs;
2531         X509                    *cert = NULL;
2532 +       ASN1_BIT_STRING         *cert_pubkey = NULL;
2533         FILE                    *fp;
2534         int                     i;
2535 +       ASN1_BIT_STRING         *request_pubkey =
2536 +                                       request->req_info->pubkey->public_key;
2537
2538         localcert = NULL;
2539
2540 @@ -66,29 +69,44 @@
2541
2542         /* Find cert */
2543         for (i = 0; i < sk_X509_num(certs); i++) {
2544 -               char buffer[1024];
2545 -
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)
2550                 if (v_flag) {
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));
2562 +                       printf("\n");
2563                 }
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) {
2568 +                       if (v_flag)
2569 +                               printf("  public keys of request and certificate don't match\n");
2570 +                       continue;
2571 +               }
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))) {
2576 -
2577 -                       /* The subject cannot be the issuer (selfsigned) */
2578 -                       if (X509_NAME_cmp(X509_get_subject_name(cert),
2579 -                               X509_get_issuer_name(cert))) {
2580 -                                       localcert = cert;
2581 -                                       break;
2582 +                       if (v_flag) {
2583 +                               printf("  certificate subject names doesn't match request subject name:\n           ");
2584 +                               fu_print_name(X509_REQ_get_subject_name(request));
2585 +                               printf("\n");
2586                         }
2587 -               }
2588 +                       continue;
2589 +               }
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))) {
2594 +                       if (v_flag)
2595 +                               printf("  certificate is self signed\n");
2596 +                       continue;
2597 +               }
2598 +               localcert = cert;
2599 +               break;
2600         }
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) */
2605
2606  void
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) {
2611 +        FILE *file;
2612 +       if (!(file = fopen(filename, "r"))) {
2613 +               fprintf(stderr, "%s: cannot open cert file %s\n", pname, filename);
2614                 exit (SCEP_PKISTATUS_FILE);
2615         }
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);
2622         }
2623 -       fclose(localfile);
2624 +       fclose(file);
2625  }
2626
2627  /* Read private key */
2628
2629  void
2630 -read_key(void) {
2631 +read_key(EVP_PKEY** key, char* filename) {
2632 +        FILE *file;
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);
2639         }
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);
2646         }
2647 -       fclose(keyfile);
2648 +       fclose(file);
2649  }
2650
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
2655 @@ -61,6 +61,9 @@
2656                                         if (!(i_char = strdup(str2)))
2657                                                 error_memory();
2658                                         }
2659 +                       } else if (!strncmp(str1, "CheckSubjectName", 16)) {
2660 +                               if (!strncmp(str2, "yes", 3) && !C_flag)
2661 +                                       C_flag = 1;
2662                         } else if (!strncmp(str1, "CertReqFile", 11)) {
2663                                 if (!r_flag) {
2664                                         r_flag = 1;
2665 @@ -114,6 +117,12 @@
2666                                         if (!(l_char = strdup(str2)))
2667                                                 error_memory();
2668                                 }
2669 +                       } else if (!strncmp(str1, "SignCertFile", 12)) {
2670 +                               if (!O_flag) {
2671 +                                       O_flag = 1;
2672 +                                       if (!(O_char = strdup(str2)))
2673 +                                               error_memory();
2674 +                               }
2675                         } else if (!strncmp(str1, "MaxPollCount", 12)) {
2676                                 if (!n_flag) {
2677                                         n_flag = 1;
2678 @@ -130,6 +139,12 @@
2679                                         if (!(k_char = strdup(str2)))
2680                                                 error_memory();
2681                                         }
2682 +                       } else if (!strncmp(str1, "SignKeyFile", 11)) {
2683 +                               if (!K_flag) {
2684 +                                       K_flag = 1;
2685 +                                       if (!(K_char = strdup(str2)))
2686 +                                               error_memory();
2687 +                                       }
2688                         } else if (!strncmp(str1, "SelfSignedFile", 15)) {
2689                                 if (!L_flag) {
2690                                         L_flag = 1;
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
2694 @@ -28,7 +28,8 @@
2695         PKCS7                   *p7enc;
2696         PKCS7_SIGNER_INFO       *si;
2697         STACK_OF(X509_ATTRIBUTE) *attributes;
2698 -       X509                    *signer = NULL;
2699 +       X509                    *signercert = NULL;
2700 +       EVP_PKEY                *signerkey = NULL;
2701
2702         /* Create a new sender nonce for all messages
2703          * XXXXXXXXXXXXXX should it be per transaction? */
2704 @@ -47,7 +48,8 @@
2705                         s->request_type_str = SCEP_REQUEST_PKCSREQ_STR;
2706
2707                         /* Signer cert */
2708 -                       signer = s->selfsigned;
2709 +                       signercert = s->signercert;
2710 +                       signerkey = s->signerkey;
2711
2712                         /* Create inner PKCS#7  */
2713                         if (v_flag)
2714 @@ -71,7 +73,8 @@
2715                         s->request_type_str = SCEP_REQUEST_GETCERTINIT_STR;
2716
2717                         /* Signer cert */
2718 -                       signer = s->selfsigned;
2719 +                       signercert = s->signercert;
2720 +                       signerkey = s->signerkey;
2721
2722                         /* Create inner PKCS#7  */
2723                         if (v_flag)
2724 @@ -95,7 +98,8 @@
2725                         s->request_type_str = SCEP_REQUEST_GETCERT_STR;
2726
2727                         /* Signer cert */
2728 -                       signer = localcert;
2729 +                       signercert = localcert;
2730 +                       signerkey = rsa;
2731
2732                         /* Read data in memory bio */
2733                         databio = BIO_new(BIO_s_mem());
2734 @@ -115,7 +119,8 @@
2735                         s->request_type_str = SCEP_REQUEST_GETCRL_STR;
2736
2737                         /* Signer cert */
2738 -                       signer = localcert;
2739 +                       signercert = localcert;
2740 +                       signerkey = rsa;
2741
2742                         /* Read data in memory bio */
2743                         databio = BIO_new(BIO_s_mem());
2744 @@ -217,9 +222,9 @@
2745         }
2746
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);
2756 @@ -317,7 +322,8 @@
2757         STACK_OF(X509_ATTRIBUTE)        *attribs;
2758         char                            *p;
2759         unsigned char                   buffer[1024];
2760 -       X509                            *recipient;
2761 +       X509                            *recipientcert;
2762 +       EVP_PKEY                        *recipientkey;
2763
2764         /* Create new memory BIO for outer PKCS#7 */
2765         memorybio = BIO_new(BIO_s_mem());
2766 @@ -547,10 +553,14 @@
2767
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;
2772 -       else
2773 -               recipient = localcert;
2774 +           (s->request_type == SCEP_REQUEST_GETCERTINIT)) {
2775 +               recipientcert = s->signercert;
2776 +               recipientkey = s->signerkey;
2777 +       }
2778 +       else {
2779 +               recipientcert = localcert;
2780 +               recipientkey = rsa;
2781 +       }
2782         if (v_flag)
2783                 printf("%s: reading inner PKCS#7\n",pname);
2784         p7enc = d2i_PKCS7_bio(outbio, NULL);
2785 @@ -568,7 +578,7 @@
2786         outbio = BIO_new(BIO_s_mem());
2787         if (v_flag)
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
2797 @@ -156,7 +156,8 @@
2798         }
2799
2800         /* Copy the pointer and return */
2801 -       s->selfsigned = cert;
2802 +       s->signercert = cert;
2803 +       s->signerkey = rsa;
2804         return (0);
2805  }
2806
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
2810 @@ -53,12 +53,15 @@
2811         }
2812         /* Skip first parameter and parse the rest of the command */
2813         optind++;
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)
2816                  switch(c) {
2817                         case 'c':
2818                                 c_flag = 1;
2819                                 c_char = optarg;
2820                                 break;
2821 +                       case 'C':
2822 +                               C_flag = 1;
2823 +                               break;
2824                         case 'd':
2825                                 d_flag = 1;
2826                                 break;
2827 @@ -86,6 +89,10 @@
2828                                 k_flag = 1;
2829                                 k_char = optarg;
2830                                 break;
2831 +                       case 'K':
2832 +                               K_flag = 1;
2833 +                               K_char = optarg;
2834 +                               break;
2835                         case 'l':
2836                                 l_flag = 1;
2837                                 l_char = optarg;
2838 @@ -98,6 +105,10 @@
2839                                 n_flag = 1;
2840                                 n_num = atoi(optarg);
2841                                 break;
2842 +                       case 'O':
2843 +                               O_flag = 1;
2844 +                               O_char = optarg;
2845 +                               break;
2846                         case 'p':
2847                                 p_flag = 1;
2848                                 p_char = optarg;
2849 @@ -137,6 +148,7 @@
2850                                 w_char = optarg;
2851                                 break;
2852                         default:
2853 +                         printf("argv: %s\n", argv[optind]);
2854                                 usage();
2855                  }
2856         argc -= optind;
2857 @@ -402,15 +414,38 @@
2858                 case SCEP_OPERATION_GETCERT:
2859                 case SCEP_OPERATION_GETCRL:
2860                         /* Read local certificate */
2861 -                       read_local_cert();
2862 +                       if (!l_flag) {
2863 +                         fprintf(stderr, "%s: missing local cert (-l)\n", pname);
2864 +                         exit (SCEP_PKISTATUS_FILE);
2865 +                       }
2866 +                       read_cert(&localcert, l_char);
2867
2868                 case SCEP_OPERATION_ENROLL:
2869                         /*
2870                          * Read in CA cert, private key and certificate
2871                          * request in global variables.
2872                          */
2873 -                       read_ca_cert();
2874 -                       read_key();
2875 +                       read_ca_cert();
2876 +
2877 +                       if (!k_flag) {
2878 +                         fprintf(stderr, "%s: missing private key (-k)\n", pname);
2879 +                         exit (SCEP_PKISTATUS_FILE);
2880 +                       }
2881 +                       read_key(&rsa, k_char);
2882 +
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);
2886 +                       }
2887 +
2888 +                       if (K_flag) {
2889 +                         read_key(&renewal_key, K_char);
2890 +                       }
2891 +
2892 +                       if (O_flag) {
2893 +                         read_cert(&renewal_cert, O_char);
2894 +                       }
2895 +
2896                         if (operation_flag == SCEP_OPERATION_ENROLL)
2897                                 read_request();
2898
2899 @@ -426,7 +461,14 @@
2900                         if (v_flag)
2901                                   fprintf(stdout, "%s: generating selfsigned "
2902                                         "certificate\n", pname);
2903 -                       new_selfsigned(&scep_t);
2904 +
2905 +                       if (! O_flag)
2906 +                         new_selfsigned(&scep_t);
2907 +                       else {
2908 +                         /* Use existing certificate */
2909 +                         scep_t.signercert = renewal_cert;
2910 +                         scep_t.signerkey = renewal_key;
2911 +                       }
2912
2913                         /* Write the selfsigned certificate if requested */
2914                         if (L_flag) {
2915 @@ -436,7 +478,7 @@
2916                                           "file for writing\n", pname);
2917                                         exit (SCEP_PKISTATUS_ERROR);
2918                                 }
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);
2924 @@ -643,7 +685,8 @@
2925
2926  void
2927  usage() {
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"
2934 @@ -665,6 +708,8 @@
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"
2943 @@ -672,6 +717,8 @@
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
2955 @@ -36,10 +36,9 @@
2956  #include <openssl/objects.h>
2957  #include <openssl/asn1_mac.h>
2958
2959 -
2960  /* Global defines */
2961
2962 -#define        VERSION "20030417"
2963 +#define        VERSION "20060428"
2964
2965  /* SCEP operations */
2966  int operation_flag;
2967 @@ -128,13 +127,13 @@
2968  X509 *encert;
2969  X509 *localcert;
2970  X509 *othercert;
2971 +X509 *renewal_cert;
2972  X509_REQ *request;
2973  EVP_PKEY *rsa;
2974 +EVP_PKEY *renewal_key;
2975  X509_CRL *crl;
2976  FILE *cafile;
2977  FILE *reqfile;
2978 -FILE *keyfile;
2979 -FILE *localfile;
2980  FILE *otherfile;
2981  FILE *crlfile;
2982
2983 @@ -207,7 +206,9 @@
2984         int recipient_nonce_len;
2985
2986         /* Certificates */
2987 -       X509 *selfsigned;
2988 +       X509 *signercert;
2989 +       EVP_PKEY *signerkey;
2990 +
2991         EVP_PKEY *pkey;
2992
2993         /* Request */
2994 @@ -251,13 +252,13 @@
2995  int init_scep(void);
2996
2997  /* Read RSA private key file */
2998 -void read_key(void);
2999 +void read_key(EVP_PKEY** key, char* filename);
3000
3001  /* Read CA certificate file */
3002  void read_ca_cert(void);
3003
3004  /* Read local certificate file */
3005 -void read_local_cert(void);
3006 +void read_cert(X509** cert, char* filename);
3007
3008  /* Read certificate request and private key */
3009  void read_request(void);