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