idnits 2.17.1 draft-nourse-scep-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 36. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2148. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 38) being 71 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 31 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 69 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 425: '...tificate. A CA MAY run in automatic ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 921 has weird spacing: '... as the signe...' == Line 985 has weird spacing: '...content pkcsC...' == Line 1448 has weird spacing: '...lIssuer issue...' == Line 1678 has weird spacing: '...rovides a way...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 572, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 572, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 572, but not defined == Missing Reference: 'RA' is mentioned on line 1359, but not defined -- Looks like a reference, but probably isn't: '0' on line 1818 == Unused Reference: 'PKCS7' is defined on line 1753, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 1756, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 1759, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2314 (ref. 'PKCS10') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Xiaoyi Liu 2 draft-nourse-scep-13.txt Cheryl Madson 3 expires 2 Dec 2006 David McGrew 4 (revised 2 Jun 2006) Andrew Nourse 5 Cisco Systems 7 Category: Informational 2-Jun-2006 9 Cisco Systems' Simple Certificate Enrollment Protocol(SCEP): 11 Status of this Memo 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This memo provides information for the Internet community. This memo 29 does not specify an Internet standard of any kind. Distribution of 30 this memo is unlimited. 32 By submitting this Internet-Draft, each author represents 33 that any applicable patent or other IPR claims of which he 34 or she is aware have been or will be disclosed, and any of 35 which he or she becomes aware will be disclosed, in 36 accordance with Section 6 of BCP 79. 38 Abstract 40 This document specifies the Simple Certificate Enrollment Protocol, 41 a PKI communication protocol which leverages existing technology by 42 using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment 43 protocol developed by Verisign, Inc. for Cisco Systems, Inc. 44 It now enjoys wide support in both client and CA implementations. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3 50 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3 51 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7 52 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10 53 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 54 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13 55 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14 56 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14 57 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 59 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 60 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 61 5.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . 16 62 5.2 Poll for Requester Initial Certificate . . . . . . . . . . 22 63 5.3 Certificate Access . . . . . . . . . . . . . . . . . . . . 26 64 5.4 CRL Access . . . . . . . . . . . . . . . . . . . . . . . 27 65 5.5 Get Certificate Authority Certificate . . . . . . . . . . 31 66 5.6 Get Certificate Authority Certificate Chain . . . . . . . 33 67 6. Security Considerations . . . . . . . . . . . . . . . . . 33 68 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33 70 Appendix A. Cisco Requester Subject Name Definition . . . . . . 34 71 Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 72 Appendix C. Private OID Definitions . . . . . . . . . . . . . 36 73 Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36 74 Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37 75 Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40 76 Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41 77 Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42 78 Appendix Y. Author Contact Information. . . . . . . . . . . . . 43 79 Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43 81 Section 1. Introduction 83 Public key technology is becoming more widely deployed and is becoming 84 the basis for standards based security, such as the Internet Engineering 85 Task Force's IPSEC and IKE protocols. With the use of public key 86 certificates in network security protocols comes the need for a 87 certificate management protocol that Public Key Infrastructure (PKI) 88 clients and Certificate Authority servers can use to support certificate 89 life cycle operations such as certificate enrollment and revocation, and 90 certificate and CRL access. 92 In the following, Section 2 gives an overview of the PKI operations, 93 and Section 2.4 describes the security goals of the protocol and the 94 mechanisms used to achieve them. The transport protocol and the 95 security protocol PKCS#7 are described at Section 3 and Section 4, 96 respectively. The last section, Section 5, specifies each PKI 97 operation in terms of the message formats and the data structures of 98 each operation. 100 The appendices provide detailed specifications and examples. Requester 101 subject names are specified in Appendix A, attribute OIDs are 102 specified in Appendix C , and the SCEP state transitions are described 103 in Appendix E. An example of a certificate enrollment request is 104 provided in Appendix B, and an example LDAP query URL encoding is 105 provided in Appendix D. 107 The authors would like to thank Peter William of ValiCert, Inc. 108 (formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and 109 Christopher Welles of IRE, Inc. for their contributions to this protocol 110 and to this document. 112 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 114 2.0 The Goal of SCEP 115 The goal of SCEP is to support the secure issuance of certificates to 116 network devices in a scalable manner, using existing technology whenever 117 possible. The protocol supports the following operations: 119 CA and RA public key distribution 120 Certificate enrollment 121 Certificate revocation 122 Certificate query 123 CRL query 125 Certificate and CRL access can be achieved by using the LDAP protocol 126 (as specified in Appendix D), or by using the query messages defined in 127 SCEP. The use of HTTP certificate and CRL access, and the support of 128 CDP as specified in RFC2459, will be specified in a future version of 129 this document. In Section 2.1, we first define PKI entity types as well 130 as the properties of each entity type. In Section 2.2, the PKI 131 operations are described at functional level. Section 2.3 describes the 132 transaction behavior of each PKI operations. The complete PKI messages 133 are covered in Section 5. 135 2.1 SCEP Entity types 137 The entity types defined in SCEP are the "requester" type (i.e., IPSEC 138 clients), the Certificate Authority (CA) entity type, and the 139 Registration Authority entity type (RA). A requester is sometimes 140 called a "SCEP client" in the following. 142 2.1.1 Requesters 144 A requester is an entity whose name is defined in a certificate 145 subject name field and optionally, in SubjectAltName, a X.509 146 certificate V3 extension. As a requester, a SCEP client is identified 147 by a subject name consisting of the following naming attributes: 149 Fully qualified domain name, for example, router.cisco.com 150 IP address, Serial number, and/or x.500 distinguished name 152 The fully qualified domain name is required for a requester that intends 153 to use the certificate for ISAKMP. The IP address, serial number, and 154 x.500 distinguished name are optional name attributes. In the 155 certificate enrollment request, the PKCS#10 subject field contains the 156 required and optional name attributes. The distinguished name, if any, 157 should be the subject name field, while any domain name, serial number, 158 or IP address supplied should be in the subjectAltName field. The 159 subject name field may be empty (if there is no distinguished name) 160 or the subjectAltName may be omitted, but not both. 162 It is important to note that a client named as Alice.cisco.com is 163 different than a client named as Alice.cisco.com plus the IP address 164 name attribute 117.96.1.219. From CA point of view, the Distinguished 165 names assigned in these two cases are distinct names. 167 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 169 Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP 170 address and User FQDN) must be presented in certificate's SubjectAltName 171 extension. Multiple IPSEC entity names, (if any) are encoded as multiple 172 values of a single SubjectAltName extension. The CA has the authority 173 to assign a distinguished name to a requester, whether or not one was 174 included in the request. The assigned DN should contain the SCEP client 175 names as the relative DN. 177 The attribute identifiers and an example of SCEP client subject name are 178 specified in Appendix A. Appendix B has an example from Cisco VPN Client 179 enrollment request. 181 2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness 183 A requester is required to generate asymmetric key pairs and to provide 184 storage to store its private keys. If the requester does not have enough 185 permanent memory to save its certificate, then it should be able to query 186 its own certificate from the CA or an LDAP server, once the certificate 187 has been issued. The public key pairs can be generated with a specific 188 key usage. The key usage is conveyed to the CA through the certificate 189 enrollment request. All current SCEP client implementations expect that 190 there will be only one pair of keys for a given subject name 191 and key usage combination and CA, at any time. This property is called 192 the certificate-name uniqueness property, and it implies that a CA that 193 implements SCEP will enforce the unique mapping between a SCEP client 194 subject name and its key pairs with a given key usage. At any time, if 195 the subject name is changed, or if the key is updated, the existing 196 certificate would have to be revoked before a new one could be issued. 198 It is desirable that the CA enforce certificate-name uniqueness, but 199 it is not mandatory. However a CA that does not enforce uniqueness 200 must provide some other mechanism to prevent the re-transmission of an 201 enrollment request by a SCEP client from creating a second certificate 202 or certificate request, nor can the second request merely be rejected. 203 If a client times out from polling for a pending request it can 204 resynchronize by reissuing the original request with the original 205 subject name, key, and transaction ID. This should return the status of 206 the original transaction, including the certificate if it was granted. 207 It should not create a new transaction unless the original cert has been 208 revoked, or the transaction arrives more than halfway through the 209 validity time of the original certificate. 211 An enrollment request that occurs more than halfway through the validity 212 time of an existing certificate for the same subject name and key usage 213 MAY be interpreted as a re-enrollment or renewal request and accepted. 214 A new certificate with new validity dates may be issued, even though 215 the old one is still valid, if the CA policy permits, as described in 216 2.1.1.3. See also appendix G. 218 2.1.1.2 Requester authentication 220 As with every protocol that uses public-key cryptography, the 221 association between the public keys used in the protocol and the 222 identities with which they are associated must be authenticated in a 223 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 225 cryptographically secure manner. This requirement is needed to 226 prevent a "man in the middle" attack, in which an adversary that can 227 manipulate the data as it travels between the protocol participants 228 can subvert the security of the protocol. To satisfy this 229 requirement, SCEP provides two authentication methods: manual 230 authentication, and authentication based on pre-shared secret. In the 231 manual mode, the requester is required to wait until its identity can 232 be verified by the CA operator using any reliable out-of-band 233 method. To prevent a "man-in-the-middle" attack, a SHA-1, SHA-256, 234 SHA-512, or MD5 `fingerprint' generated on the PKCS#10 (before PKCS #7 235 enveloping and signing) must be compared out-of-band between the 236 server and the requester. SCEP clients and CAs (or RAs, if 237 appropriate) must display this fingerprint to the operator to enable 238 this verification if manual mode is used. Failing to provide this 239 information leaves the protocol vulnerable to attack by sophisticated 240 adversaries. When utilizing a pre-shared secret scheme, the server 241 should distribute a shared secret to the requester which can uniquely 242 associate the enrollment request with the given end entity. The 243 distribution of the secret must be private: only the end entity should 244 know this secret. The actual binding mechanism between the requester 245 and the secret is subject to the server policy and implementation. 246 When creating the enrollment request, the requester is asked to 247 provide a challenge password. When using the pre-shared secret scheme, 248 the requester must enter the re-distributed secret as the password. In 249 the manual authentication case, the challenge password only used to 250 authenticate a request for the certificate's revokation. This 251 challenge password is included as a PKCS#10 attribute, and is sent to 252 the server as encrypted data. The PKCS#7 envelope protects the 253 privacy of the challenge password with DES encryption. 255 2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates 257 In this protocol, the communication between the requester and the 258 certificate authority is secured by using PKCS#7 as the messaging 259 protocol. PKCS#7, however, is a protocol which assumes the 260 communicating entities already possess the peer's certificates and 261 requires both parties use the issuer names and issuer assigned 262 certificate serial numbers to identify the certificate in order to 263 verify the signature and decrypt the message. If the requesting 264 system already has a certificate issued by the CA, that certificate 265 may be presented as credentials for the renewal of that certificate if 266 the CA supports the "Renewal" capability and the CA policy permits the 267 certificate to be renewed. If the requester has no certificate issued 268 by the CA, or if the CA does not support and permit renewal, the 269 requestor must generate a self-signed certificate with the requester 270 subject name (the same name later used in the PKCS#10) as both issuer 271 and subject name. During the certificate enrollment, the requester 272 will first post itself as the signing authority by attaching the 273 self-signed certificate to the signed certificate request. When the 274 Certificate Authority makes the envelope on the issued certificate 275 using the public key included in the self-signed certificate, it 276 should use the same issuer name and serial number as conveyed in the 277 self-signed certificate to inform the end entity on which private key 278 should be used to open the envelope. 280 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 282 Note that when a client enrolls for separate encryption and signature 283 certificates, it may use the signature certificate to sign both 284 requests, and then expect its signature key to be used to encrypt 285 both responses. In any case, the recipientinfo on the envelope should 286 reflect the key used to encrypt the request. 288 2.1.1.4 Trusted CA Store 290 To support interoperability between IPSEC peers whose certificates are 291 issued by different CA, SCEP allows the users to configure multiple 292 trusted certificates. Trusted certificates are have been configured as 293 such in the client, based on some out-of-band means such as a "fingerprint". 294 These trusted certificates are used to verify certificate chains that end 295 in those certificates. 297 2.1.2 Certificate Authority 299 A Certificate Authority(CA) is an entity whose name is defined in the 300 certificate issuer name field. Before any PKI operations can begin, 301 the CA generates its own public key pair and creates a self-signed CA 302 certificate, or causes another CA to issue a certificate to it. 303 Associated with the CA certificate is a fingerprint which will be used 304 by the requester to authenticate the received CA certificate if it is 305 self-signed. The fingerprint is created by calculating a SHA-1, 306 SHA-256, SHA-512, or MD5 hash on the whole CA certificate. Before any 307 requester can start its enrollment, this CA certificate has to be 308 configured at the entity side securely. For IPSEC clients, the client 309 certificates must have SubjectAltName extension. To utilize LDAP as a 310 CRL query protocol, the certificates must have a CRL Distribution 311 Point. Key usage is optional. Without key usage, the public key is 312 assumed as a general purpose public key and it can be used for all the 313 purposes. 315 A Certificate Authority may enforce certain name policy. When using 316 X.500 directory name as the subject name, all the name attributes 317 specified in the PKCS#10 request should be included as Relative DN. All 318 the name attributes as defined in RFC2459 should be specified in the 319 SubjectAltName. An example is provided in Appendix A. 321 If there is no LDAP query protocol support, the Certificate Authority 322 should answer certificate and CRL queries, and to this end it should be 323 online all the time. 325 The updating of the CA's public key is addressed in Appendix G. 327 2.1.3 Registration Authorities 329 In an environment where an RA is present, a requester performs 330 enrollment through the RA. In order to setup a secure channel with an RA 331 using PKCS#7, the RA certificate(s) have to be obtained by the client 332 in addition to the CA certificate(s). 334 In the following, the CA and RA are specified as one entity in the 335 context of PKI operation definitions. 337 2.2 SCEP Operations Overview 339 In this section, we give a high level overview of the PKI operations as 340 defined in SCEP. 342 2.2.1 Requester Initialization 344 The requester initialization includes the key pair generation and the 345 configuring of the required information to communicate with the 346 certificate authority. 348 2.2.1.1 Key Pairs 350 Before a requester can start PKI transaction, it must have at least one 351 asymmetric key pair, using the selected algorithm (the RSA algorithm is 352 required in SCEP, and is the only algorithm in current implementations). 354 Key pairs may be intended for particular purposes, such as encryption only, 355 or signing only. The usage of any associated certificate can be restricted 356 by adding key usage and extended key usage attributes to the PKCS#10. 358 2.2.1.2 Required Information 360 A requester is required to have the following information configured 361 before starting any PKI operations: 363 1. the certificate authority IP address or fully-qualified domain name, 364 2. the certificate authority HTTP CGI script path, and 365 the HTTP proxy information in case there is no direct Internet 366 connection to the server, 367 3. If CRLs are being published by the CA to an LDAP directory server, 368 and there is a CRL Distribution Point containing only an X.500 directory 369 name, then the client will need to know the LDAP server fully-qualified 370 domain name or IP address. CRL Distribution Points are discussed in 371 more detail in RFC 2459. 373 2.2.2 CA/RA Certificate Distribution 375 Before any PKI operation can be started, the requester needs to get 376 the CA/RA certificates. At this time, since no public key has been 377 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 379 exchanged between the requester and the CA/RA, the message to get the 380 CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the 381 CA/RA certificate distribution is implemented as a clear HTTP Get 382 operation. After the requester gets the CA certificate, it has to 383 authenticate the CA certificate by comparing the finger print with the 384 CA/RA operator. Since the RA certificates are signed by the CA, there is 385 no need to authenticate the RA certificates. 387 This operation is defined as a transaction consisting of one HTTP Get 388 message and one HTTP Response message: 390 REQUESTER CA SERVER 391 Get CA/RA Cert: HTTP Get message 392 -----------------------------> 393 CA/RA Cert download: HTTP Response message 394 <--------------------------------------- 395 Compute finger print and 396 call CA operator. 397 Receive call and check finger print 399 If an RA is in use, a degenerated PKCS#7 with a certificate chain 400 consisting of both RA and CA certificates is sent back to the end 401 entity. Otherwise the CA certificate is directly sent back as the 402 HTTP response payload. 404 2.2.3 Certificate Enrollment 406 A requester starts an enrollment transaction by creating a certificate 407 request using PKCS#10 and sends it to the CA/RA enveloped using the 408 PKCS#7. After the CA/RA receives the request, it will either 409 automatically approve the request and send the certificate back, or it 410 will require the requester to wait until the operator can manually 411 authenticate the identity of the requester. Two attributes are 412 included in the PKCS#10 certificate request - a Challenge Password 413 attribute and an optional ExtensionReq attribute which will be a 414 sequence of extensions the requester would like to be included in its 415 V3 certificate extensions. The Challenge Password may be used to 416 authenticate either the enrollment request itself, or a verbal 417 revocation request for the issued certificate in the event of key 418 compromise or other reason. 420 In the automatic mode, the transaction consists of one PKCSReq PKI 421 Message, and one CertRep PKI message. In the manual mode, the requester 422 enters into polling mode by periodically sending a GetCertInitial PKI 423 message to the server, until the server operator completes the manual 424 authentication, after which the CA will respond to GetCertInitial by 425 returning the issued certificate. A CA MAY run in automatic mode for 426 preapproved requests, and manual mode for the rest. A request with a 427 non-null password is not necessarily a pre-approved request. It is up 428 to the CA server to decide. Polling mode is entered whenever the 429 server returns a PENDING response. 431 The transaction in automatic mode: 433 REQUESTER CA SERVER 435 PKCSReq: PKI cert. enrollment msg 436 --------------------------------> CertRep: pkiStatus = SUCCESS 437 certificate attached 438 <------------------------------ 439 Receive issued certificate. 441 The transaction in manual mode: 443 REQUESTER CA SERVER 444 PKCSReq: PKI cert. enrollment msg 445 --------------------------------> CertRep: pkiStatus = PENDING 446 <------------------------------ 447 GetCertInitial: polling msg 448 --------------------------------> CertRep: pkiStatus = PENDING 449 <------------------------------ 450 ................. CertRep: pkiStatus = SUCCESS 454 certificate attached 455 <------------------------------ 456 Receive issued certificate. 458 2.2.4 Requester Certificate Revocation 460 A requester should be able to revoke its own certificate. Currently 461 the revocation is implemented as a manual process. In order to revoke a 462 certificate, the requester makes a phone call to the CA server 463 operator. The operator will come back asking the ChallengePassword 464 (which has been sent to the server as an attribute of the PKCS#10 465 certificate request). If the ChallengePassword matches, the certificate 466 is revoked. The reason of the revocation is documented by CA/RA. 468 2.2.5 Certificate Access 470 There are two methods to query certificates. The first method is to use 471 LDAP as a query protocol. Using LDAP to query assumes the client 472 understand the LDAP scheme supported by the CA. The SCEP client assumes 473 that the subject DN name in the certificate is used as the URL to query the 474 certificate. The standard attributes (userCertificate and caCertificate) 475 are used as filter. 477 For the environment where LDAP is not available, a certificate query 478 message is defined to retrieve the certificates from the CA. 480 To query a certificate from the certificate authority, a requester 481 sends a request consisting of the certificate's issuer name and the 482 serial number. This assumes that the requester has saved the issuer 483 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 485 name and the serial number of the issued certificate from the previous 486 enrollment transaction. The transaction to query a certificate consists 487 of one GetCert PKI message and one CertRep PKI message: 489 REQUESTER CA SERVER 490 GetCert: PKI cert query msg 491 -------------------------------> CertRep: pkiStatus = SUCCESS 492 certificate 493 attached 494 <----------------------------- 495 Receive the certificate. 497 2.2.6 CRL Distribution 499 The CA/RA will not "push" the CRL to the end entities. The query of the 500 CRL can only be initialized by the requester. 502 There are three methods to query CRL. 504 The CRL may be retrieved by a simple HTTP GET. If the CA supports this 505 method, it should encode the URL into a CRL Distribution Point extension 506 in the certificates it issues. Support for this method should be 507 incorporated in new and updated clients, but may not be in older 508 versions. 510 The second method is to query CRL using LDAP. This assumes the CA server 511 supports CRL LDAP publishing and issues the CRL Distribution Point in 512 the certificate. The CRL Distribution Point is encoded as a DN. Please 513 refer to Appendix D for the examples of CRL Distribution Point. 515 The third method is implemented for the CA which does not support LDAP 516 CRL publishing or does not implement the CRL Distribution Point. In this 517 case, a CRL query is composed by creating a message consists of the CA 518 issuer name and the CA's certificate serial number. This method is 519 deprecated because it does not scale well and requires the CA to be a 520 high-availability service. 522 The message is sent to the CA in the same way as the other SCEP 523 requests: The transaction to query CRL consists of one GetCRL PKI 524 message and one CertRep PKI message which have no certificates but CRL. 526 REQUESTER CA SERVER 527 GetCRL: PKI CRL query msg 528 ----------------------------------> CertRep: CRL attached 529 <-------------------------------- 531 2.3 PKI Operation Transactional Behavior 533 As described before, a PKI operation is a transaction consisting of the 534 messages exchanged between a requester and the CA/RA. This section 535 will specify the transaction behavior on both the requester and the 536 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 538 certificate authority server. Because the protocol is basically a two 539 way communication protocol without a confirmation message from the 540 initiating side, state and state resynchronization rules have to be 541 defined, in case any error happens at either side. Before the state 542 transition can be defined, the notion of transaction identifier has to 543 be defined first. 545 2.3.1 Transaction Identifier 547 A transaction identifier is a string generated by the entity when 548 starting a transaction. Since all the PKI operations defined in this 549 protocol are initiated by the requester, it is the responsibility of 550 the requester to generate a unique string as the transaction 551 identifier. All the PKI messages exchanged for a given PKI transaction 552 must carry the same transaction identifier. The transaction 553 identifier is generated as a SHA-1, SHA-256, SHA-512 or MD5 hash on 554 the public key value for which the enrollment request is made. This 555 allows the SCEP client to reuse the same transaction identifier if it 556 is reissuing a request for the same certificate (i.e. a certificate 557 with the same subject, issuer, and key). The SCEP protocol requires 558 that transaction identifiers be unique, so that queries can be matched 559 up with transactions. For this reason, in those cases in which 560 separate signing and encryption certificates are issued to the same 561 requester, the keys must be different. 563 2.3.2 State Transitions in Certificate Enrollment 565 The requester state transitions during enrollment operation are 566 indicated in the diagram below: 567 +-<------+ 568 | | 569 GetCertInitial triggered by timeout or 570 | | manual authentication 571 | | 572 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 573 | PKCSReq | CertRep with SUCCESS 574 | | 575 | | 576 +--------<-------------------+ 577 request rejected, timeout, or error 579 As described in the section 2.2.3, certificate enrollment starts at the 580 state CERT-NONEXISTANT. Sending PKCSReq changes the state to 581 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 582 state to CERT-ISSUED. In the case the server sending back the response 583 with pending status, the requester will keep polling certificate 584 response by sending GetCertInitial to the server, until either a CertRep 585 with SUCCESS status is received, or the maximum polling number has been 586 exceeded. 588 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 589 entity will transition to the CERT-NONEXISTANT state. 591 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 593 The client administrator will, eventually, start up another enrollment 594 request. It is important to note that, as long as the requester does 595 not change its subject name or keys, the same transaction id will be 596 used in the "new" transaction. This is important because based on this 597 transaction id, the certificate authority server can recognize this as 598 an existing transaction instead of a new one. 600 2.3.3 Transaction Behavior of Certificate/CRL Access 602 There is no state maintained during certificate access and CRL access 603 transaction. When using the certificate query and CRL query messages 604 defined in this protocol, the transaction identifier is still required 605 so that the requester can match the response message with the 606 upstanding request message. When using LDAP to query the certificate and 607 the CRL, the behavior is specified by the LDAP protocol. 609 2.4 Security 611 The security goals of SCEP are that no adversary can: 613 o subvert the public key/identity binding from that intended, 614 o discover the identity information in the enrollment requests and 615 issued certificates, 616 o cause the revocation of certificates with any non-negligible 617 probability. 619 Here an adversary is any entity other than the requester and the CA 620 (and optionally the RA) participating in the protocol that is 621 computationally limited, but that can manipulate data during 622 transmission (that is, a man-in-the-middle). The precise meaning of 623 'computationally limited' depends on the implementer's choice of 624 cryptographic hash functions and ciphers. The required algorithms are 625 RSA, DES and MD5. Depending on the CA Capabilities, Triple-DES may 626 be used instead of DES, and SHA-1, SHA-256, or SHA-512 may be used 627 instead of MD5. [See Appendix F]. 629 The first and second goals are met through the use of PKCS#7 and PKCS#10 630 encryption and digital signatures using authenticated public keys. The 631 CA's public key is authenticated via the checking of the CA fingerprint, 632 as specified in Section 2.1.2, and the SCEP client's public key is 633 authenticated through the manual authentication or pre-shared secret 634 authentication, as specified in Section 2.1.1.2. The third goal is met 635 through the use of a Challenge Password for revocation, that is chosen 636 by the SCEP client and communicated to the CA protected by the PKCS#7 637 encryption, as specified in Section 2.2.4. 639 The motivation of the first security goal is straightforward. The 640 motivation for the second security goal is to protect the identity 641 information in the enrollment requests and certificates. For example, 642 two IPSEC hosts behind a firewall may need to exchange certificates, and 643 may need to enroll certificates with a CA that is outside of a firewall. 645 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 647 Most networks with firewalls seek to prevent IP addresses and DNS 648 information from the trusted network leaving that network. The second 649 goal enables the hosts in this example to enroll with a CA outside the 650 firewall without revealing this information. The motivation for the 651 third security goal is to protect the SCEP clients from denial of 652 service attacks. 654 Section 3 Transport Protocol 656 In the SCEP protocol, HTTP is used as the transport protocol for the PKI 657 messages. 659 3.1 HTTP "GET" and "POST" Message Format 661 The following is the syntax definition of a HTTP GET message sent from 662 a requester to a certificate authority server: 664 Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 665 where: 666 CGI-PATH defines the actual CGI path to invoke the CGI program which 667 parses the request. 668 CGI-PROG is set to be the string "pkiclient.exe". This is intended 669 to be the program that the CA will use to handle the SCEP transactions, 670 though the CA may ignore CGI-PROG and use only the CGI-PATH. 671 OPERATION is set to be the string "PKIOperation" when the GET message 672 carries a PKI message to request certificates or CRL; OPERATION is set 673 to be the string "GetCACaps", "GetCACert", "GetNextCACert" or 674 "GetCACertChain" when the GET operation is used to get CA capabilities, 675 CA/RA certificate, the replacement CA/RA certificates for when the 676 current ones expire, or the CA Cert chain (respectively). 678 When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI message, 679 When OPERATION is GetCACert, MESSAGE is a CRL distribution 680 point in URI format, otherwise, MESSAGE is a string which represents 681 the certificate authority issuer identifier. 683 SCEP uses the HTTP "GET" and "POST" messages to request information from the CA. 684 Requests for CA certificates or capabilities are sent in the clear, using "GET", 685 with the OPERATION and MESSAGE fields identifying the requested data. 686 CRLs may also be requested in the clear if the CA supports it. 688 Other types of requests are sent using the PKCS#7 secure protocol. 689 These may be issued by means of a GET operation with 690 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 691 identifies the type of GET operation, and MESSAGE is actually the PKCS#7 692 message Base64-Encoded. 694 For example. a requester may submit a message via HTTP to the server 695 as follows: 697 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 698 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== 699 If supported by the CA, the message may also be sent via HTTP POST: 701 POST /cgi-bin/pkiclient.exe?operation=PKIOperation 703 This is further described in Appendix H. 704 To determine if the CA supports POST, use the GetCACaps message described 705 in Appendix F. 707 3.2 Response Message Format 709 For each GET operation, the CA/RA server will return a MIME object via 710 HTTP. For a GET operation with PKIOperation as its type, the response is 711 tagged as having a Content Type of application/x-pki-message. The body 712 of this message is a BER encoded binary PKI message. The following is an 713 example of the response: 715 "Content-Type:application/x-pki-message\n\n" 717 In the case of GET operation with a type of GetCACert the MIME content 718 type returned will depend on whether or not an RA is in use. If there 719 is no RA, only the CA certificate is sent back in the response, and 720 the response has the content type tagged as 721 application/x-x509-ca-cert. the body of the response is a DER encoded 722 binary X.509 certificate. For example: 724 "Content-Type:application/x-x509-ca-cert\n\n" 726 If there is an RA, the RA certificates are sent back together with the 727 CA certificates, a certificate-only PKCS#7 SignedData is sent back in 728 the response where the SignerInfo is empty. Section 5 has the detailed 729 definition of the message format in this case. The content type is 730 application/x-x509-ca-ra-cert. 732 The response to GetNextCACert is always a certificates-only PKCS#7 733 SignedData with a content type of application/x-x509-ca-ra-cert. 734 If there is an RA, The signer is the current RA certificate. Otherwise, 735 the signer is the current CA certificate. 737 If the CA supports it, PKIOperation may also be done via an HTTP POST. 738 This is described in Appendix H. 740 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 742 Section 4 Secure Transportation: PKCS#7 744 PKCS#7 is a general enveloping mechanism that enables both signed and 745 encrypted transmission of arbitrary data. It is widely implemented and 746 included in the RSA tool kit. In this section, the general PKCS#7 747 enveloped PKI message format is specified. The complete PKCS#7 message 748 format for each PKI transaction will be covered in Section 5. 750 4.1 SCEP Message Format 752 As a transaction message, a SCEP message has a set of transaction 753 specific attributes and an information portion. Employing PKCS#7 754 protocol, the transaction specific attributes are encoded as a set of 755 authenticated attributes of the SignedData. The information portion will 756 first be encrypted to become Enveloped Data, and then the digest of the 757 enveloped information portion is included as one of the message digest 758 attributes and being signed together with the other transaction specific 759 attributes. 761 By applying both enveloping and signing transformations, a SCEP message 762 is protected both for the integrity of its end-end-transition 763 information and the confidentiality of its information portion. The 764 advantage of this technique over the conventional transaction message 765 format is that, the signed transaction type information and the status 766 of the transaction can be determined prior to invoke security handling 767 procedures specific to the information portion being processed. 769 The following is an example of a SCEP message with its enveloped and 770 signed data portion represented by pkcsPKISigned and 771 pkcsPKIEnveloped. The out-most of any PKI message is a blob of 772 ContentInfo, with its content type set to SignedData and the actual 773 signed data as the content. 775 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 777 pkiMessage ContentInfo ::= { 778 contentType {pkcs-7 signedData(2)} 779 content pkcsPKISigned 780 } 781 pkcsPKISigned SignedData ::= { 782 version 1 783 digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) 784 digestAlgorithm(2) 5} 785 contentInfo { 786 contentType {pkcs-7 1} -- data content identifier 787 content pkcsPKIEnvelope -- enveloped information portion 788 } 789 certificates -- signer certificate chain 790 signerInfo -- including signed transaction info and the digest 791 -- of the enveloped information portion as the 792 -- authenticated attributes 793 } 794 pkcsPKIEnveloped EnvelopedData ::= { 795 version 0 796 recipientInfos -- information required to open the envelop 797 encryptedContentInfo { 798 contentType {pkcs-7 1} -- data content identifier 799 contentEncryptionAlgorithm 800 encryptedContent -- encrypted information portion 801 } 802 } 804 4.2 Signed Transaction Attributes 806 The following transaction attributes are encoded as authenticated 807 attributes. Please refer to Appendix B for the OID definitions. 809 transactionID PrintableString -- Decimal value as a string 810 messageType PrintableString -- Decimal value as a string 811 pkiStatus PrintableString -- Decimal value as a string 812 failinfo PrintableString -- Decimal value as a string 813 senderNonce Octet String 814 recipientNonce Octet String 816 where: 818 The transactionID is an attribute which uniquely identify a 819 transaction. This attribute is required in all PKI messages. 821 The messageType attribute specify the type of operation performed by the 822 transaction. This attribute is required in all PKI 823 messages. Currently, the following message types are defined: 825 PKCSReq (19) -- Permits use of PKCS#10 certificate request 826 CertRep (3) -- Response to certificate or CRL request 827 GetCertInitial (20) -- Certificate polling in manual enrollment 828 GetCert (21) -- Retrieve a certificate 829 GetCRL (22) -- Retrieve a CRL 830 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 832 All response message will include transaction status information which 833 is defined as pkiStatus attribute: 835 SUCCESS (0) -- request granted 836 FAILURE (2) -- request rejected 837 PENDING (3) -- request pending for manual approval. 839 If the status in the response is FAILURE, the failinfo attribute will 840 contain one of the following failure reasons: 842 badAlg (0) -- Unrecognized or unsupported algorithm ident 843 badMessageCheck (1) -- integrity check failed 844 badRequest (2) -- transaction not permitted or supported 845 badTime (3) -- Message time field was not sufficiently close 846 to the system time 847 badCertId (4) -- No certificate could be identified matching 848 the provided criteria 850 The attributes of senderNonce and recipientNonce are the 16 byte 851 random numbers generated for each transaction to prevent the replay 852 attack. 854 When a requester sends a PKI message to the server, a senderNonce is 855 included in the message. After the server processes the request, it will 856 send back the requester senderNonce as the recipientNonce and generates 857 another nonce as the senderNonce in the response message. Because the 858 proposed pki protocol is a two-way communication protocol, it is clear 859 that the nonce can only be used by the requester to prevent the 860 replay. The server has to employ extra state related information to 861 prevent a replay attack. 863 Section 5. SCEP Transaction Specification 865 In this section each SCEP transaction is specified in terms of the 866 complete messages exchanged during the transaction. 868 5.1 Certificate Enrollment 870 The certificate enrollment transaction consists of one PKCSReq message 871 sent to the certificate authority from a requester, and one CertRep 872 message sent back from the server. The pkiStatus returned in the 873 response message is either SUCCESS, or FAILURE, or PENDING. The 874 information portion of a PKCSReq message is a PKCS#10 certificate 875 request, which contains the subject Distinguished Name, the subject 876 public key, and two attributes, a ChallengePassword attribute to be used 877 for revocation, and an optional ExtensionReq attribute which will be a 878 sequence of extensions the requester expects to be included in its V3 879 certificate extensions. One of the extension attribute specifies the key 880 usage. If the request is granted, the pkiStatus is set to SUCCESS, and 881 the certificate is returned in CertRep; if the request is rejected, the 882 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 884 pkiStatus is set to FAILURE; if the server requires manual approval of 885 the request, the pkiStatus is set to PENDING. The messages exchanged 886 in the manual authentication mode is further specified in Section 5.2. 888 Precondition: 889 Both the requester and the certificate authority have completed their 890 initialization process. The requester has already been configured 891 with the CA/RA certificate. 893 Postcondition: 894 Either the certificate is received by the requester, or the end 895 entity is notified to do the manual authentication, or the request 896 is rejected. 898 5.1.1 PKCSReq Message Format 900 A PKCSReq message is created by following the steps defined below: 902 1. Create a PKCS#10 certificate request which is signed by the end 903 entity's private key, corresponding to the public key included in 904 the PKCS#10 certificate request. This constitutes the information 905 portion of PKCSReq. 907 2. Encrypt the PKCS#10 certificate request using a randomly generated 908 content-encryption key. This content-encryption key is then 909 encrypted by the CA's* public key and included in the recipientInfo. 910 This step completes the "envelope" for the PKCS#10 certificate 911 request. 913 3. Generate a unique string as the transaction id. 915 4. Generate a 16 byte random number as senderNonce. 917 5. Generate message digest on the enveloped PKCS#10 certificate request 918 using the selected digest algorithm. 920 6. Create SignedData by adding the requester's self- or CA-certificate 921 as the signer's public key certificate. Include the message type, 922 transaction id, the senderNonce and the message digest as the 923 authenticated attributes and sign the attributes using the end 924 entity's private key. This completes the SignedData. 926 7. The SignedData is prepended with the ContenInfo blob which indicates 927 a SignedData object. This final step completes the create of a 928 complete PKCSReq PKI message. 930 In the following, the PKCSReq message is defined following the ASN.1 931 notation. 933 For readability, the values of a field is either represented by a quoted 934 string which specifies the intended value, or a constant when the value 935 is known. 937 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 939 -- PKCSReq information portion 940 pkcsCertReq CertificationRequest ::= { -- PKCS#10 941 version 0 942 subject "the requester's subject name" 943 subjectPublicKeyInfo { 944 algorithm {pkcs-1 1} -- rsa encryption 945 subjectPublicKey "DER encoding of the requester's public key" 946 } 947 attributes { 948 challengePassword {{pkcs-9 7} "password string" } 949 extensions 950 } 951 signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption 952 signature "bit string which is created by signing inner content 953 of the defined pkcsCertReq using requester's private 954 key, corresponding to the public key included in 955 subjectPublicKeyInfo." 956 } 957 -- Enveloped information portion 958 pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 959 version 0 960 recipientInfo { 961 version 0 962 issuerAndSerialNumber { 963 issuer "the CA issuer name" 964 serialNumber "the CA certificate serial number" 965 } 966 keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 967 encryptedKey "content-encryption key 968 encrypted by CA public key" 969 } 970 encryptedContentInfo { 971 contentType {pkcs-7 1} -- data content 972 contentEncryptionAlgorithm "object identifier 973 for DES encryption" 974 encryptedContent "encrypted pkcsCertReq using the content- 975 encryption key" 976 } 977 } 978 -- Signed PKCSReq 979 pkcsCertReqSigned SignedData ::= { -- PKCS#7 980 version 1 981 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 982 digestAlgorithm(2) 5} 983 contentInfo { 984 contentType {pkcs-7 1} -- data content identifier 985 content pkcsCertReqEnvelope 986 } 987 certificate { -- requester self-signed or CA-issued certificate 988 version 3 989 serialNumber "the transaction id associated with enrollment" 990 signature {pkcs-1 4} -- md5WithRSAEncryption 991 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 993 issuer " the requester's subject name" 994 validity { 995 notBefore "a UTC time" 996 notAfter "a UTC time" 997 } 998 subject "the requester's subject name" 999 subjectPublicKeyInfo { 1000 algorithm {pkcs-1 1} 1001 subjectPublicKey "DER encoding of requester's public key" 1002 } 1003 signatureAlgorithm {pkcs-1 4} 1004 signature "the signature generated by using the requester's 1005 private key corresponding to the public key in 1006 this certificate." 1007 } 1008 signerInfo { 1009 version 1 1010 issuerAndSerialNumber { 1011 issuer "the requester's subject name" 1012 serialNumber "the transaction id associated 1013 with the enrollment" 1014 } 1015 digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) 1016 digestAlgorithm(2) 5} 1017 authenticateAttributes { 1018 contentType {{pkcs-9 3} {pkcs-7 1}} 1019 messageDigest {{pkcs-9 4} "an octet string"} 1020 transaction-id {{id-attributes transId(7)} "printable 1021 string"} 1022 -- this transaction id will be used 1023 -- together with the subject name as 1024 -- the identifier of the requester's key 1025 -- pair during enrollment 1026 messageType {{id-attributes messageType(2)} "PKCSReq"} 1027 senderNonce {{id-attributes senderNonce(5)} 1028 "a random number encoded as a string"} 1029 } 1030 digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption 1031 encryptedDigest "encrypted digest of the authenticated 1032 attributes using requester's private key" 1033 } 1034 } 1035 pkcsReq PKIMessage ::= { 1036 contentType {pkcs-7 2} 1037 content pkcsCertReqSigned 1038 } 1039 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1041 5.1.2 CertRep Message Format 1043 The response to an SCEP enrollment request is a CertRep message. 1045 5.1.2.1 PENDING Response 1047 When the CA is configured to manually authenticate the requester, 1048 the CertRep is returned with the attribute pkiStatus set to PENDING. 1049 The data portion for this message is null. Only the transaction 1050 required attributes are sent back. 1052 CertRepSigned SignedData ::= { -- PKCS#7 1053 version 1 1054 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1055 digestAlgorithm(2) 5} 1056 contentInfo {contentType {pkcs-7 1} -- empty content 1057 } 1058 signerInfo { 1059 version 1 1060 issuerAndSerialNumber { 1061 issuer "name of CA that issued the CA [RA] cert" 1062 serialNumber "the serial number of the CA [RA] cert" 1063 } 1064 digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) 1065 digestAlgorithm(2) 5} 1066 authenticateAttributes { 1067 contentType {{pkcs-9 3} {pkcs-7 1}} 1068 messageDigest {{pkcs-9 4} NULL} 1069 messageType {{id-attribute messageType(0)} "CertRep"} 1070 transaction-id {{id-attributes transid(7)} "printablestring"} 1071 --- same transaction id used in PKCSReq 1072 pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} 1073 recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} 1074 senderNonce {{id-attributes senderNonce(5)} <16 bytes>} 1075 } 1076 digestEncrytionAlgorithm {pkcs-1 1} 1077 encryptedDigest "encrypted message digest of the authenticated 1078 attributes using the CA's [RA's] private key" 1079 } 1080 } 1081 CertRep PKIMessage ::= { 1082 contentType {pkcs-7 2} 1083 content CertRepSigned 1084 } 1086 5.1.2.2 Failure Response 1088 In this case, the CertRep sent back to the requester is same as in 1089 the PENDING case, except that the pkiStatus attribute is set to FAILURE, 1090 and the failInfo attribute should be included: 1092 pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} 1093 failInfo {{id-attributes failInfo(4)} "the reason to reject"} 1094 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1096 5.1.2.3 SUCCESS response 1098 In this case, the information portion of CertRep will be a degenerated 1099 PKCS#7 which contains the requester's certificate. It is then enveloped 1100 and signed as below: 1102 pkcsCertRep SignedData ::= { -- PKCS#7 1103 version 1 1104 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1105 digestAlgorithm(2) 5} 1106 contentInfo { -- empty content since this is degenerated PKCS#7 1107 contentType {pkcs-7 1} 1108 } 1109 certificates { 1110 certificate { -- issued requester's certificate // must be first 1111 version 3 1112 serialNumber "issued requester's certificate serial number" 1113 signature {pkcs-1 4} -- md5WithRSAEncryption 1114 issuer "the certificate authority issuer name" 1115 validity { 1116 notBefore "UTC time" 1117 notAfter "UTC time" 1118 } 1119 subject "the requester subject name as given in PKCS#10" 1120 subjectPublicKeyInfo { 1121 algorithm {pkcs-1 1} 1122 subjectPublicKey "a DER encoding of requester public 1123 key as given in PKCS#10" 1124 } 1125 extensions " the extensions as given in PKCS#10" 1126 signatureAlgorithm {pkcs-1 4} 1127 signature " the certificate authority signature" 1128 } 1129 certificate "the certificate authority certificate" (optional) 1130 certificate "the registration authority certificate(s)" (optional) 1131 } 1132 } 1133 pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 1134 version 0 1135 recipientInfo { 1136 version 0 1137 issuerAndSerialNumber { -- use issuer name and serial number as 1138 -- conveyed in requester's self-signed 1139 -- certificate, included in the PKCSReq 1140 issuer "the requester's subject name" 1141 serialNumber "the serial number defined by the requester in 1142 its self-signed certificate" 1143 } 1144 keyEncryptionAlgorithm {pkcs-1 1} 1145 encryptedKey "content-encrypt key encrypted by the requester's 1146 public key which is same key as authenticated in 1147 the requester's certificate" 1148 } 1149 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1151 encryptedContentInfo { 1152 contentType {pkcs-7 1} -- data content identifier 1153 contentEncryptionAlgorithm "OID for DES encryption" 1154 encryptedContent "encrypted pkcsCertRep using content encryption 1155 key" 1156 } 1157 } 1158 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1159 version 1 1160 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1161 digestAlgorithm(2) 5} 1162 contentInfo { 1163 contentType {pkcs-7 1} 1164 content pkcsCertRepEnvelope 1165 } 1166 signerInfo { 1167 version 1 1168 issuerAndSerialNumber { 1169 issuer "the certificate authority issuer name" 1170 serialNumber "the CA certificate's serial number" 1171 } 1172 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1173 digestAlgorithm(2) 5} 1174 authenticateAttributes { 1175 contentType {{pkcs-9 3} {pkcs-7 1}} 1176 messageDigest {{pkcs-9 4} "a octet string"} 1177 messageType {{id-attribute messageType(2)} "CertRep"} 1178 transaction-id {{id-attributes transId(7)} "printable 1179 string"} 1180 -- same transaction id as given in PKCSReq 1181 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1182 recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} 1183 senderNonce {{ id-attributes senderNonce(5) <16 bytes>} 1184 } 1185 digestEncryptionAlgorithm {pkcs-1 1} 1186 encryptedDigest "encrypted digest of authenticate attributes 1187 using CA's private key " 1188 } 1189 } 1190 CertRep PKIMessage ::= { 1191 contentType {pkcs-7 2} 1192 content pkcsCertRepSigned 1193 } 1195 5.2 Poll for Requester Initial Certificate 1197 Either triggered by the PENDING status received from the CertRep, or by 1198 the non-response timeout for the previous PKCSReq, a requester will 1199 enter the polling state by periodically sending GetCertInitial to the 1200 server, until either the request is granted and the certificate is sent 1201 back, or the request is rejected, or the configured time limit for 1202 polling is exceeded. 1204 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1206 Since GetCertInitial is part of the enrollment, the messages exchanged 1207 during the polling period should carry the same transaction identifier 1208 as the previous PKCSReq. 1210 PreCondition 1211 Either the requester has received a CertRep with pkiStatus set to be 1212 PENDING, or the previous PKCSReq has timed out. 1214 PostContition 1215 The requester has either received the certificate, or be rejected of 1216 its request, or the polling period ended as a failure. 1218 5.2.1 GetCertInitial Message Format 1220 Since at this time the certificate has not been issued, the requester 1221 can only use the requester's subject name, combined with the 1222 transaction identifier, to identify the polled certificate request. 1224 The certificate authority server must be able to uniquely identify the 1225 polled certificate request. A subject name can have more than one 1226 outstanding certificate request (with different key usage attributes). 1228 -- Information portion 1230 pkcsGetCertInitial issuerAndSubject ::= { 1231 issuer "the certificate authority issuer name" 1232 subject "the requester subject name as given in PKCS#10" 1233 } 1234 pkcsGetCertInitialEnvelope EnvelopedData ::= { 1235 version 0 1236 recipientInfo { 1237 version 0 1238 issuerAndSerialNumber { 1239 issuer "the CA issuer name" 1240 serialNumber "the CA certificate serial number" 1241 } 1242 keyEncryptionAlgorithm {pkcs-1 1} 1243 encryptedKey "content-encrypt key encrypted by CA's public key" 1244 } 1245 encryptedContentInfo { 1246 contentType {pkcs-7 1} -- data content 1247 contentEncryptionAlgorithm "OID for DES encryption" 1248 encryptedContent "encrypted getCertInital" 1249 } 1250 } 1251 pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 1252 version 1 1253 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1254 digestAlgorithm(2) 5} 1255 contentInfo { 1256 contentType {pkcs-7 1} 1257 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1259 content pkcsGetCertIntialEnvelope 1260 } 1261 certificate { -- the requester's self-signed certificate 1262 version 3 1263 serialNumber "the transaction id associated with enrollment" 1264 signature {pkcs-1 4} -- md5WithRSAEncryption 1265 issuer " the requester's subject name" 1266 validity { 1267 notBefore "a UTC time" 1268 notAfter "a UTC time" 1269 } 1270 subject "the requester's subject name" 1271 subjectPublicKeyInfo { 1272 algorithm {pkcs-1 1} 1273 subjectPublicKey "DER encoding of requester's public key" 1274 } 1275 signatureAlgorithm {pkcs-1 4} 1276 signature "the signature generated by using the requester's 1277 private key corresponding to the public key in 1278 this certificate." 1279 } 1280 signerInfo { 1281 version 1 1282 issuerAndSerialNumber { 1283 issuer "requester's subject name" 1284 serialNumber "the transaction id used in previous PKCSReq" 1285 } 1286 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1287 digestAlgorithm(2) 5} 1288 authenticateAttributes { 1289 contentType {{pkcs-9 3} {pkcs-7 1}} 1290 messageDigest {{pkcs-9 4} "an octet string"} 1291 -- digest of getCertInitial 1292 messageType {{id-attribute messageType(2)} "GetCertInitial"} 1293 transaction-id {{id-attributes transId(7)} "printable 1294 string"} 1295 -- same transaction idused in previous PKCSReq 1296 senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} 1297 } 1298 digestEncryptionAlgorithm {pkcs-1 1} 1299 encryptedDigest "encrypted digest of authenticateAttributes" 1300 } 1301 } 1302 GetCertInitial PKIMessage ::= { 1303 contentType {pkcs-7 2} 1304 content pkcsGetCertInitialSigned 1305 } 1307 5.2.2 GetCertInitial Response Message Format 1309 The response messages for GetCertInitial are the same as for PKCSReq. 1311 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1313 5.3 Certificate Access 1315 The certificate query message defined in this section is an option when 1316 the LDAP server is not available to provide the certificate query. A 1317 requester should be able to query an issued certificate from the 1318 certificate authority, as long as the issuer name and the issuer 1319 assigned certificate serial number is known to the requesting end 1320 entity. This transaction is not intended to provide the service as a 1321 certificate directory service. A more complicated query mechanism would 1322 have to be defined in order to allow a requester to query a certificate 1323 using various different fields. 1325 This transaction consists of one GetCert message sent to the server by 1326 a requester, and one CertRep message sent back from the server. 1328 PreCondition 1329 The queried certificate have been issued by the certificate authority 1330 and the issuer assigned serial number is known. 1332 PostCondition 1333 Either the certificate is sent back or the request is rejected. 1335 5.3.1 GetCert Message Format 1337 The queried certificate is identified by its issuer name and the issuer 1338 assigned serial number. If this is a query for an arbitrary requester's 1339 certificate, the requesting requester should includes its own CA issued 1340 certificate in the signed envelope. If this is a query for its own 1341 certificate (assume the requester lost the issued certificate, or does 1342 not have enough non-volatile memory to save the certificate), then the 1343 self-signed certificate has to be included in the signed envelope. 1345 pkcsGetCert issuerAndSerialNumber ::= { 1346 issuer "the certificate issuer name" 1347 serialNumber "the certificate serial number" 1348 } 1349 pkcsGetCertEnvelope EnvelopedData ::= { 1350 version 0 1351 recipientInfo { 1352 version 0 1353 issuerAndSerialNumber { 1354 issuer "the CA [RA] issuer name" 1355 serialNumber "the CA [RA] certificate serial number" 1356 } 1357 keyEncryptionAlgorithm {pkcs-1 1} 1358 encryptedKey "content-encrypt key encrypted 1359 by CA [RA] public key" 1360 } 1361 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1363 encryptedContentInfo { 1364 contentType {pkcs-7 1} -- data content 1365 contentEncryptionAlgorithm "OID for DES encryption" 1366 encryptedContent "encrypted pkcsGetCert using the content 1367 encryption key" 1368 } 1369 } 1370 pkcsGetCertSigned SignedData ::= { 1371 version 1 1372 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1373 digestAlgorithm(2) 5} 1374 contentInfo { 1375 contentType {pkcs-7 1} 1376 content pkcsGetCertEnvelope 1377 } 1378 certificates { 1379 certificate "CA issued certificate" 1380 or "self-signed certificate" 1381 } 1382 signerInfo { 1383 version 1 1384 issuerAndSerialNumber { 1385 issuer "the requester's subject name" 1386 serialNumber "requester's certificate serial number" 1387 } 1388 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1389 digestAlgorithm(2) 5} 1390 authenticateAttributes { 1391 contentType {{pkcs-9 3} {pkcs-7 1}} 1392 messageDigest {{pkcs-9 4} "an octet string"} 1393 -- digest of pkcsGetCertEnvelope 1394 messageType {{id-attribute messageType(2)} "GetCert"} 1395 transaction-id {{id-attributes transId(7)} "printable 1396 string"} 1397 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1398 } 1399 digestEncryptionAlgorithm {pkcs-1 1} 1400 encryptedDigest "encrypted digest of authenticateAttributes" 1401 } 1402 } 1403 GetCert PKIMessage ::= { 1404 contentType {pkcs-7 2} 1405 content pkcsGetCertSigned 1406 } 1407 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1409 5.3.2 CertRep Message Format 1411 In this case, the CertRep from the server is same as the CertRep for the 1412 PKCSReq, except that the server will only either grant the request or 1413 reject the request. Also, the recipientInfo should use the CA issuer 1414 name and CA assigned serial number to identify the requester's key pair 1415 since at this time, the requester has received its own certificate. 1417 5.4 CRL Access 1419 The CRL query message defined in this section is an option when the LDAP 1420 server is not available to provide the CRL query. In the PKI protocol 1421 proposed here, only the requester can initiate the transaction to 1422 download CRL. A requester sends GetCRL request to the server and the 1423 server sends back CertRep whose information portion is a degenerated 1424 PKCS#7 which contains only the most recent CRL. The size of CRL included 1425 in the CertRep should be determined by the implementation. 1427 PreCondition 1428 The certificate authority certificate has been downloaded to the end 1429 entity. 1431 PostCondition 1432 CRL sent back to the requester. 1434 5.4.1 GetCRL Message format 1436 The CRL is identified by using both CA's issuer name and the CA 1437 certificate's serial number: 1439 pkcsGetCRL issuerAndSerialNumber { 1440 issuer "the certificate authority issuer name" 1441 serialNumber "certificate authority certificate's serial number" 1442 } 1444 When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as 1445 the following: 1447 pkcsGetCRL SEQUENCE { 1448 crlIssuer issuerAndSerialNumber 1449 distributionPoint CE-CRLDistPoints 1450 } 1452 where CE-CRLDisPoints is defined in X.509, but must contain only one 1453 CRL distribution point. 1455 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1457 pkcsGetCRLEnvelope EnvelopedData ::= { 1458 version 0 1459 recipientInfo { 1460 version 0 1461 issuerAndSerialNumber { 1462 issuer "the certificate authority (or RA) issuer name" 1463 serialNumber "the CA (RA) certificate's serial number" 1464 } 1465 keyEncryptionAlgorithm {pkcs-1 1} 1466 encryptedKey "content-encrypt key encrypted by CA (RA) public key" 1467 } 1468 encryptedContentInfo { 1469 contentType {pkcs-7 1} -- data content 1470 contentEncryptionAlgorithm "OID for DES encryption" 1471 encryptedContent "encrypted pkcsGetCRL" 1472 } 1473 } 1474 pkcsGetCRLSigned SignedData ::= { 1475 version 1 1476 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1477 digestAlgorithm(2) 5} 1478 contentInfo { 1479 contentType {pkcs-7 1} 1480 content pkcsGetCRLEnvelope 1481 } 1482 certificates { 1483 certificate "CA-issued or self-signed requester's certificate" 1484 } 1485 signerInfo { 1486 version 1 1487 issuerAndSerialNumber { 1488 issuer "the requester's issuer name" 1489 serialNumber "the requester's certificate serial number" 1490 } 1491 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1492 digestAlgorithm(2) 5} 1493 authenticateAttributes { 1494 contentType {{pkcs-9 3} {pkcs-7 1}} 1495 messageDigest {{pkcs-9 4} 0x<16/20 bytes>} 1496 -- digest of pkcsGetCRLEnvelope 1497 messageType {{id-attribute messageType(2)} "GetCRL"} 1498 transaction-id {{id-attributes transId(7)} "printable 1499 string"} 1500 senderNonce {{id-attribute senderNonce(3)} <16 bytes>} 1501 } 1502 digestEncryptionAlgorithm {pkcs-1 1} 1503 encryptedDigest "encrypted digest of authenticateAttributes" 1504 } 1505 } 1506 GetCRL PKIMessage ::= { 1507 contentType {pkcs-7 2} 1508 content pkcsGetCRLSigned 1509 } 1510 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1512 5.4.2 CertRep Message Format 1514 The CRL is sent back to the requester through CertRep message. The 1515 information portion of this message is a degenerated PKCS#7 SignedData 1516 which contains only a CRL. 1518 pkcsCertRep SignedData ::= { 1519 version 1 1520 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1521 digestAlgorithm(2) 5} 1522 contentInfo { 1523 contentType {pkcs-7 1} 1524 } 1525 crl { 1526 signature {pkcs-1 4} 1527 issuer "the certificate authority issuer name" 1528 lastUpdate "UTC time" 1529 nextUpdate "UTC time" 1530 revokedCertificate { 1531 -- the first entry 1532 userCertificate "certificate serial number" 1533 revocationData "UTC time" 1534 .... 1535 -- last entry 1536 userCertificate "certificate serial number" 1537 revocationData "UTC time" 1538 } 1539 } 1540 pkcsCertRepEnvelope EnvelopedData ::= { 1541 version 0 1542 recipientInfo { 1543 version 0 1544 issuerAndSerialNumber { 1545 issuer "the requester's issuer name" 1546 serialNumber "the requester certificate serial number" 1547 } 1548 keyEncryptionAlgorithm {pkcs-1 1} 1549 encryptedKey "content-encrypt key encrypted by requester's 1550 public key " 1551 } 1552 encryptedContentInfo { 1553 contentType {pkcs-7 1} -- data content 1554 contentEncryptionAlgorithm "OID for DES encryption" 1555 encryptedContent "encrypted pkcsCertRep using requester's 1556 public key" 1557 } 1558 } 1559 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1561 pkcsCertRepSigned SignedData ::= { -- PKCS#7 1562 version 1 1563 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1564 digestAlgorithm(2) 5} 1565 contentInfo { 1566 contentType {pkcs-7 1} 1567 content pkcsCertRepEnvelope 1568 } 1569 signerInfo { 1570 version 1 1571 issuerAndSerialNumber { 1572 issuer "the certificate authority issuer name" 1573 serialNumber "the CA certificate's serial number" 1574 } 1575 digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) 1576 digestAlgorithm(2) 5} 1577 authenticateAttributes { 1578 contentType {{pkcs-9 3} {pkcs-7 1}} 1579 messageDigest {{pkcs-9 4} "an octet string"} 1580 -- digest of pkcsCertRepEnvelope 1581 messageType {{id-attribute messageType(2)} "CertRep"} 1582 transaction-id {{id-attributes transId(7)} "printable 1583 string"} 1584 -- same transaction id as given in PKCSReq 1585 pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} 1586 recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} 1587 senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} 1588 } 1589 digestEncryptionAlgorithm {pkcs-1 1} 1590 encryptedDigest "encrypted digest of authenticatedAttributes 1591 using CA private key" 1592 } 1593 } 1595 NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but 1596 SCEP entities must also accept a sequence of octet strings as a valid 1597 alternate encoding. 1599 This alternate encoding must be accepted wherever PKCS #7 Enveloped 1600 Data is specified in this document. 1602 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1604 5.5 Get Certificate Authority Certificate 1606 Before any transaction begins, end entities have to get the CA (and 1607 possibly RA) certificate(s) first. Since the requester may have no CA 1608 certificates or CA public keys at all, this message can not be 1609 encrypted and the response must be authenticated by out-of-band means. 1610 These certs are obtained by means of an HTTP GET message. To get the 1611 CA certificate, the requester does a "HTTP GET" with a URL that 1612 identifies a CGI script on the server and an optional CA issuer 1613 identifier as the parameter to the CGI script. The response is either 1614 a single X.509 CA certificate ("CA mode"), or a PKCS7 message 1615 containing the CA certificate and RA certificates ("RA mode"). The 1616 client can determine which mode the CA operates in by which response 1617 it gets. Once the CA certificate is received by the requester, a 1618 fingerprint is generated using the SHA1, SHA256, SHA512 or MD5 hash 1619 algorithm on the whole CA certificate. If the requester does not have 1620 a certificate path to a trusted CA certificate, this fingerprint may 1621 be used to verify the certificate, by some positive out-of-band means, 1622 such as a phone call. 1624 5.5.1 GetCACert HTTP Message Format 1625 "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT 1626 where: 1627 CGI-PATH defines the actual CGI path to invoke the CGI program 1628 which parses the request. 1629 CGI-PROG is set to be the string "pkiclient.exe" and this is 1630 expected to be the program that the CA will use to handle the 1631 SCEP transactions. 1632 CA-IDENT is any string which is understood by the CA. 1633 For example, it could be a domain name like ietf.org. 1634 If a certificate authority has multiple CA certificates 1635 this field can be used to distinguish which is required. 1636 Otherwise it may be ignored. 1638 5.5.2 Response 1640 The response for GetCACert is different between the case where the CA 1641 directly communicated with the requester during the enrollment, and the 1642 case where a RA exists and the requester communicates with the RA 1643 during the enrollment. 1645 5.5.2.1 CA Certificate Only Response 1647 A binary X.509 CA certificate is sent back as a MIME object with a 1648 Content-Type of application/x-x509-ca-cert. 1650 5.5.2.2 CA and RA Certificates Response 1652 When an RA exists, both CA and RA certificates must be sent back in 1653 the response to the GetCACert request. The RA certificate(s) must be 1654 signed by the CA. A certificates-only PKCS#7 SignedData is used to 1655 carry the certificates to the requester, with a Content-Type of 1656 application/x-x509-ca-ra-cert. 1658 5.5.3 Get Next Certificate Authority Certificate 1660 5.5.3.1 GetNextCACert HTTP Message Format 1661 "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT 1663 The response to this message is a PKCS#7 certificates-only message containing 1664 a CA certificate (and possibly RA certificates) to be used when the current CA 1665 certificate expires, signed with the current CA cert (or RA certificate, if 1666 the CA is in RA mode. Note that a PKCS#7 is returned even in CA mode. 1668 5.5.3.2 GetCACaps HTTP Message Format 1669 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1671 This message requests capabilities from CA. The response is a list of 1672 text capabilities, as defined in Appendix F. Support for this message 1673 is optional, but if it is not supported, the client should assume that 1674 none of the capabilities in Appendix F are supported. 1676 5.6 Get Certificate Authority Certificate Chain 1678 GetCACertChain provides a way to get the entire certificate chain. 1680 5.6.1 GetCACertChain HTTP Message Format 1682 "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT 1683 where CGI-SCRIPT and CA-IDENT are as described for GetCACert. 1685 5.6.2 Response 1687 The response for GetCACertChain is a certificates-only PKCS#7 SignedData 1688 to carry the certificates to the requester, with a Content-Type of 1689 application/x-x509-ca-ra-cert-chain. 1691 5.6.3 Backwards Compatability 1693 Versions of SCEP prior to revision 3 do not support GetCACertChain. 1694 Certificate Authorities written to these prior versions will not be 1695 able to process the message and may return an HTML error. 1697 To avoid this, clients should send the GetCACert message first. If the 1698 returned certificate is self-signed or is signed by a Certificate 1699 Authority that is trusted by the client, then it is not necessary to 1700 send the GetCACertChain message and it should not be sent. 1702 If a Certificate Authority is configured with a certificate that is 1703 not either self-signed or has a self-signed issuer, then it should 1704 support this message. In other words, it should be supported if the 1705 CA hierarchy is more than two-deep. 1707 An old CA in a two-deep hierarchy might still get this message from 1708 a client if the client did not trust either that CA or its issuer. 1709 In that event, the certificate cannot be trusted anyway. In any case 1710 the CA must not crash or hang upon the receipt of the message and the 1711 client must be able to handle whatever error is returned by the CA, 1712 including an HTML error or an ungraceful disconnect. 1714 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1716 The following is the ASN.1 definition of Cert-Only PKCS#7: 1718 certOnly SignedData ::= { 1719 version 1 1720 digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) 1721 digestAlgorithm(2) 5} 1723 contentInfo { 1724 contentType {pkcs-7 1} -- data content identifier 1725 content -- NULL 1726 } 1727 certificates -- the RA and CA certificates. 1728 } 1730 CARACerts PKIMessage ::= { -- special pki message sent in the clear 1731 contentType {pkcs-7 2} 1732 content certOnly 1733 } 1735 6.0 Security Considerations 1737 This entire document is about security. Common security considerations 1738 such as keeping private keys truly private and using adequate lengths 1739 for symmetric and asymmetric keys must be followed in order to maintain 1740 the security of this protocol. 1742 7.0 Intellectual Property 1744 This protcol includes the optional use of Certificate Revocation List 1745 Distribution Point (CRLDP) technology, which is a patented technology 1746 of Entrust Technologies, Inc. (Method for Efficient Management of 1747 Certificate Revocation Lists and Update Information (U.S. Patent 1748 5,699,431)). Please contact Entrust Technologies, Inc. 1749 (www.entrust.com) for more information on licensing CRLDP technology. 1751 8.0 References 1753 [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1754 1.5", RFC 2315, March 1998. 1756 [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1757 1.5", RFC 2314, March 1998. 1759 [RFC2459] Housley, R., ec. al., "Internet X.509 Public Key 1760 Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 1762 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1764 Appendix A: Cisco Requester Subject Name Definition 1766 The ip address and the FQDN of a SCEP client should be included in the 1767 V3 extension subjectAltName. When the subjectAltName extension attribute 1768 is present, both the subjectAltName fields and the subjectName field could 1769 have the IP address and the FQDN information. 1771 When the X.500 directory is used by the CA to define the name space, the 1772 subject name defined above become a RDN which is part of DN binded to 1773 the requester's public key in the certificate. 1775 A sample of DN assigned by Entrust CA is given below (assume the same 1776 ciscoRouterAlice is used as the requester defined subject name): 1778 OU = InteropTesting, O = Entrust Technologies, C = CA 1779 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1780 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1782 Appendix B: IPSEC Client Enrollment Certificate Request 1784 The following is the certificate enrollment request (PKCS#10) as created 1785 by Cisco VPN Client: 1787 -----END NEW CERTIFICATE REQUEST----- 1788 0 30 439: SEQUENCE { 1789 4 30 288: SEQUENCE { 1790 8 02 1: INTEGER 0 1791 11 30 57: SEQUENCE { 1792 13 31 55: SET { 1793 15 30 53: SEQUENCE { 1794 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1795 22 13 46: PrintableString 1796 : 'For Xiaoyi, IPSEC attrs in alternate name 1797 extn' 1798 : } 1799 : } 1800 : } 1801 70 30 158: SEQUENCE { 1802 73 30 13: SEQUENCE { 1803 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1804 1 1) 1805 86 05 0: NULL 1806 : } 1807 88 03 140: BIT STRING 0 unused bits 1808 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1809 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1810 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1811 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1812 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1813 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1814 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1815 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1816 : [ Another 11 bytes skipped ] 1817 : } 1818 231 A0 63: [0] { 1819 233 30 61: SEQUENCE { 1820 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1821 14) 1822 246 31 48: SET { 1823 248 30 46: SEQUENCE { 1824 250 30 44: SEQUENCE { 1825 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1826 257 04 37: OCTET STRING 1827 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1828 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1830 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1831 6E 2E 69 72 65 2E 63 6F 6D 1832 : } 1833 : } 1834 : } 1835 : } 1836 : } 1837 : } 1839 296 30 13: SEQUENCE { 1840 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1841 1 1 4) 1842 309 05 0: NULL 1843 : } 1844 311 03 129: BIT STRING 0 unused bits 1845 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1846 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1847 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1848 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1849 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1850 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1851 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1852 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1853 : } 1855 Appendix C: Private OID Definitions 1857 The OIDs used in defining pkiStatus are VeriSign self-maintained 1858 OIDs. Please note, work is in progress to replace the VeriSign owned 1859 object identifiers with the standard object identifiers. Once the 1860 standarlization is completed, this documentation will be updated. 1862 id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} 1863 id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} 1864 id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} 1865 id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} 1866 id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} 1867 id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} 1868 id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} 1869 id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} 1870 id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} 1871 id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} 1872 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1874 Appendix D: CRL Query by means of LDAP 1876 In order to retrieve the CRL by means of LDAP, the client needs to know 1877 where in the directory it is stored. The certificate must contain a 1878 CRL Distribution Point extension encoded as a DN or as an LDAP URI. 1880 For example, the certificate issued by Entrust VPN contains 1881 the following DN as the CRL distribution point: 1883 CN = CRL1, O = cisco, C = US. 1885 The asn.1 encoding of this distribution point is: 1887 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1888 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1889 13 04 43 52 4C 31 1891 The ldap form would be: 1893 ldap://servername/CN=CRL1,O=cisco,C=US 1895 Appendix E: SCEP State Transitions 1897 SCEP state transitions are based on transaction identifier. The design 1898 goal is to ensure the synchronization between the CA and the requester 1899 under various error situations. 1901 An identity is defined by the combination of FQDN, the IP address and 1902 the client serial number. FQDN is the required name attribute. It is 1903 important to notice that, a client named as Alice.cisco.com is different 1904 from the client named as Alice.cisco.com plus IPAddress 117.96.1.219. 1906 Each enrollment transaction is uniquely associated with a transaction 1907 identifier. Because the enrollment transaction could be interrupted by 1908 various errors, including network connection errors or client reboot, 1909 the SCEP client generates a transaction identifier by calculating a 1910 hash on the public key value for which the enrollment is requested. This 1911 retains the same transaction identifier throughout the enrollment 1912 transaction, even if the client has rebooted or timed out, and issues a 1913 new enrollment request for the same key pair. It also provides the way 1914 for the CA to uniquely identify a transaction in its database. At the 1915 requester side, it generates a transaction identifier which is included 1916 in PKCSReq. If the CA returns a response of PENDING, the requester 1917 will poll by periodically sending out GetCertInitial with the same 1918 transaction identifier until either a response other than PENDING is 1919 obtained, or the configured maximum time has elapsed. 1921 If the client times out or the client reboots, the client administrator 1922 will start another enrollment transaction with the same key pair. The 1923 second enrollment will have the transaction idenifier. At the server 1924 side, instead of accepting the PKCSReq as a new enrollment request, it 1925 should respond as if another GetCertInitial message had been sent with 1926 that transaction ID. In another word, the second PKCSReq should be 1927 taken as a resynchronization message to allow the enrollment resume as 1928 the same transaction. 1930 It is important to keep the transaction id unique since SCEP requires the 1931 same policy and same identity be applied to the same subject name and 1932 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1934 key pair binding. In the current implementation, an SCEP client can 1935 only assume one identity. At any time, only one key pair, with a given 1936 key usage, can be associated with the same identity. 1938 The following gives several examples of client to CA transactions. 1940 Client actions are indicated in the left column, CA actions are 1941 indicated in the right column. A blank action signifies that no message 1942 was received. Note that these examples assume that the CA enforces the 1943 certificate-name uniqueness property defined in Section 2.1.1.1. 1945 The first transaction, for example, would read like this: 1946 "Client Sends PKCSReq message with transaction ID 1 to the 1947 CA. The CA signs the certificate and constructs a CertRep Message 1948 containing the signed certificate with a transaction ID 1. The client 1949 receives the message and installs the cert locally." 1951 Successful Enrollment Case: no manual authentication 1952 PKCSReq (1) ----------> CA Signs Cert 1953 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1955 Successful Enrollment Case: manual authentication required 1956 PKCSReq (10) ----------> Cert Request goes into Queue 1957 Client Polls <---------- CertRep (10) PENDING 1958 GetCertInitial (10) ----------> Still pending 1959 Client Polls <---------- CertRep (10) PENDING 1960 GetCertInitial (10) ----------> Still pending 1961 Client Polls <---------- CertRep (10) PENDING 1962 GetCertInitial (10) ----------> Still pending 1963 Client Polls <---------- CertRep (10) PENDING 1964 GetCertInitial (10) ----------> Cert has been signed 1965 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1967 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1968 CertRep: 1970 PKCSReq (3) ----------> Cert Request goes into queue 1971 <---------- CertRep (3) PENDING 1972 GetCertInitial (3) ----------> 1973 <---------- CertRep (3) PENDING 1974 GetCertInitial (3) -----------> 1975 <----------- CA signed Cert and sent back 1976 CertRep(3) 1977 (Time Out) 1978 PKCSReq (3) ----------> Cert already signed, sent back to 1979 client 1980 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1981 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 1983 Case when NVRAM is lost and client has to generate a new key pair, there 1984 is no change of name information: 1986 PKCSReq (4) ----------> CA Signs Cert 1987 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1988 (Client looses Cert) 1989 PKCSReq (5) ----------> There is already a valid cert with 1990 this DN. 1991 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1992 PKCSReq (5) ----------> CA Signs Cert 1993 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1995 Case when client admin resync the enrollment using a different PKCS#10: 1996 PKCSReq (6) ----------> CA Signs Cert 1997 <---------- CertRep (6) SIGNED CERT 1998 (Client timeout and admin starts another enrollment with a different 1999 PKCS#10, but the same transaction id) 2000 PKCSReq (6) with different PKCS#10 2001 ----------> There is already a valid cert with 2002 this entity (by checking FQDN). 2003 <---------- CertRep (6) INVALID PKCS#10 CERT 2004 ERROR 2005 Client admin either revokes the existing cert 2006 or corrects the error by enrolling with 2007 the same PKCS#10 as the first PKCSReq(6) 2008 PKCSReq (6) ----------> CA find the existing Cert 2009 Client Installs Cert <---------- CertRep (6) SIGNED CERT 2011 Resync case when server is slow in response: 2012 PKCSReq (13) ----------> Cert Request goes into Queue 2013 <---------- CertRep (13) PENDING 2014 GetCertInitial ----------> Still pending 2015 <---------- CertRep (13) PENDING 2016 GetCertInitial ----------> Still pending 2017 <---------- CertRep (13) PENDING 2018 GetCertInitial ----------> Still pending 2019 <---------- CertRep (13) PENDING 2020 GetCertInitial ----------> Still pending 2021 (TimeOut) <---------- CertRep (13) PENDING 2022 * Case 1 2023 PKCSReq (13) ----------> Still pending 2024 Client polls <---------- CertRep (13) PENDING 2025 CertCertInitial ----------> Cert has been signed 2026 Client Installs Cert <---------- CertRep (13) SIGNED CERT 2027 * Case 2 2028 PKCSReq (13) ----------> Cert has been signed 2029 Client Installs Cert <---------- CertRep (13) SIGNED CERT 2030 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 2032 Appendix F. CA Capabilities 2034 The response for a GetCACaps message is a list of CA capabilities, in 2035 plain text, separated by characters, as follows (quotation marks 2036 are NOT sent): 2038 Keyword Description 2040 "GetNextCACert" CA Supports the GetNextCACert message. 2041 "POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST. 2042 "Renewal" Clients may use current certificate and key to 2043 authenticate an enrollment request for a new 2044 certificate. 2045 "SHA-512" CA Supports the SHA-512 hashing algorithm in 2046 signatures and fingerprints. 2047 "SHA-256" CA Supports the SHA-256 hashing algorithm in 2048 signatures and fingerprints. 2049 "SHA-1" CA Supports the SHA-1 hashing algorithm in 2050 signatures and fingerprints. 2051 "DES3" CA Supports triple-DES for encryption. 2053 The client should use SHA-1, SHA-256, or SHA-512 in preference to MD5 2054 hashing if it is supported by the CA. 2056 A client must be able to accept and ignore any unknown keywords that 2057 might be sent back by a CA that implements a future version of SCEP. 2059 If none of the above capabilities are supported by the CA, no data 2060 is returned. 2062 The appropriate HTML headers are returned in any case. 2064 Example: 2066 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 2068 might return: 2070 GetNextCACert 2071 POSTPKIOperation 2073 This means that the CA supports the GetNextCACert message and allows 2074 PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent 2075 using HTTP POST. 2077 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 2079 Appendix G. Certificate Renewal and CA Key Rollover 2081 To renew a client certificate, use the PKCSreq message and sign it with 2082 the existing client certificate instead of a self-signed certificate. 2084 To obtain the new CA certificate prior to the expiration of the current 2085 one, use the GetNextCACert message if the CA supports it. 2087 To obtain a new client certificate signed by the new CA certificate, 2088 use the new CA or RA certificate in the message envelope. 2090 Example: 2092 GetNextCACert ----------> 2093 <---------- CertRep (3) New CA certificate 2095 PKCSReq* (1) ----------> CA Signs certificate with NEW key 2096 Client Stores Cert <---------- CertRep (3) Certificate issued 2097 for installation when from NEW CA certificate and keypair. 2098 existing cert expires. 2100 *enveloped for new CA or RA cert and keypair. The CA will use the 2101 envelope to determine which key and certificate to use to issue the 2102 client certificate. 2104 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 2106 Appendix H. PKIOperation via HTTP POST Message 2108 If the remote CA supports it, any of the PKCS#7-encoded SCEP messages 2109 may be sent via HTTP POST instead of HTTP GET. This is allowed for 2110 any SCEP message except GetCACert, GetCACertChain, GetNextCACert, 2111 or GetCACaps. In this form of the message, Base 64 encoding is not 2112 used. 2114 POST /cgi-bin/pkiclient.exe?operation=PKIOperation 2115 2117 The client can verify that the CA supports SCEP messages via POST by 2118 looking for the "POSTPKIOperation" capability (See Appendix F). 2120 Cisco Systems' Simple Certificate Enrollment Protocol Jun 2006 2122 Appendix Y. Author Contact Information 2124 Xiaoyi Liu Cheryl Madson 2125 Cisco Cisco 2126 510 McCarthy Drive 510 McCarthy Drive 2127 Milpitas, CA Milpitas, CA. 2128 xliu@cisco.com cmadson@cisco.com 2130 David McGrew Andrew Nourse 2131 Cisco Cisco 2132 170 West Tasman Drive 510 McCarthy Drive 2133 San Jose, CA 94134 Milpitas, CA. 2134 mcgrew@cisco.com nourse@cisco.com 2136 Appendix Z. Copyright Section 2138 Copyright (C) The Internet Society (2006). This document is subject 2139 to the rights, licenses and restrictions contained in BCP 78, and 2140 except as set forth therein, the authors retain all their rights. 2142 This document and the information contained herein are provided on an 2143 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2144 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2145 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2146 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2147 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2150 This draft expires 2 Dec 2006 2152 [End of draft-nourse-scep-13.txt]