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