idnits 2.17.1 draft-nourse-scep-17.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1946. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2008) is 5782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT-NONEXISTANT' is mentioned on line 663, but not defined == Missing Reference: 'CERT-REQ-PENDING' is mentioned on line 663, but not defined == Missing Reference: 'CERT-ISSUED' is mentioned on line 663, but not defined -- Looks like a reference, but probably isn't: '0' on line 1572 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Nourse 3 Internet-Draft X. Liu 4 Intended status: Informational J. Vilhuber 5 Expires: December 28, 2008 C. Madson 6 Cisco Systems, Inc. 7 June 26, 2008 9 Cisco Systems' Simple Certificate Enrollment Protocol 10 draft-nourse-scep-17 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 28, 2008. 37 Abstract 39 This document specifies the Simple Certificate Enrollment Protocol, a 40 PKI communication protocol which leverages existing technology by 41 using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment 42 protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now 43 enjoys wide support in both client and CA implementations. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 49 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1. SCEP Entity Types . . . . . . . . . . . . . . . . . . . . 5 51 2.1.1. Requesters . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1.1.1. Local Key/Certificate/CRL Storage and 53 Certificate-name uniqueness . . . . . . . . . . . 6 54 2.1.1.2. Requester authentication . . . . . . . . . . . . . 7 55 2.1.1.3. Requester Uses Existing CA-Issued or 56 Self-Signed Certificates . . . . . . . . . . . . . 8 57 2.1.1.4. Trusted CA Store . . . . . . . . . . . . . . . . . 9 58 2.1.2. Certificate Authority . . . . . . . . . . . . . . . . 9 59 2.1.3. Registration Authorities . . . . . . . . . . . . . . . 10 60 2.2. SCEP Operations Overview . . . . . . . . . . . . . . . . . 10 61 2.2.1. Requester Initialization . . . . . . . . . . . . . . . 10 62 2.2.1.1. RSA Key Pairs . . . . . . . . . . . . . . . . . . 10 63 2.2.1.2. non-RSA Keys . . . . . . . . . . . . . . . . . . . 10 64 2.2.1.3. Required Information . . . . . . . . . . . . . . . 10 65 2.2.2. CA/RA Certificate Distribution . . . . . . . . . . . . 11 66 2.2.3. Certificate Enrollment . . . . . . . . . . . . . . . . 11 67 2.2.4. Requester Certificate Revocation . . . . . . . . . . . 12 68 2.2.5. Certificate Access . . . . . . . . . . . . . . . . . 13 69 2.2.6. CRL Distribution . . . . . . . . . . . . . . . . . . . 13 70 2.3. PKI Operation Transactional Behavior . . . . . . . . . . . 14 71 2.3.1. Transaction Identifier . . . . . . . . . . . . . . . . 14 72 2.3.2. State Transitions in Certificate Enrollment . . . . . 14 73 2.3.3. Transaction Behavior of Certificate/CRL Access . . . . 15 74 2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 16 76 3.1. HTTP "GET" and "POST" Message Format . . . . . . . . . . . 17 77 3.2. Response Message Format . . . . . . . . . . . . . . . . . 18 78 4. Secure Transportation: PKCS#7 . . . . . . . . . . . . . . . . 19 79 4.1. SCEP Message Format . . . . . . . . . . . . . . . . . . . 19 80 4.1.1. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 19 81 4.1.2. SCEP pkiMessage type . . . . . . . . . . . . . . . . . 20 82 4.2. Signed Transaction Attributes . . . . . . . . . . . . . . 20 83 4.2.1. transactionID . . . . . . . . . . . . . . . . . . . . 21 84 4.2.2. messageType . . . . . . . . . . . . . . . . . . . . . 21 85 4.2.3. pkiStatus . . . . . . . . . . . . . . . . . . . . . . 21 86 4.2.4. failInfo . . . . . . . . . . . . . . . . . . . . . . . 22 87 4.2.5. senderNonce and responderNonce . . . . . . . . . . . . 22 88 5. SCEP Transaction Specification . . . . . . . . . . . . . . . . 22 89 5.1. Certificate Enrollment . . . . . . . . . . . . . . . . . . 22 90 5.1.1. PKCSReq Message Format . . . . . . . . . . . . . . . . 23 91 5.1.2. CertRep Message Format . . . . . . . . . . . . . . . . 23 92 5.1.2.1. PENDING Response . . . . . . . . . . . . . . . . . 24 93 5.1.2.2. FAILURE Response . . . . . . . . . . . . . . . . . 24 94 5.1.2.3. SUCCESS response . . . . . . . . . . . . . . . . . 24 95 5.2. Poll for Requester Initial Certificate . . . . . . . . . . 24 96 5.2.1. GetCertInitial Message Format . . . . . . . . . . . . 25 97 5.2.2. GetCertInitial Response Message Format . . . . . . . . 25 98 5.3. Certificate Access . . . . . . . . . . . . . . . . . . . . 25 99 5.3.1. GetCert Message Format . . . . . . . . . . . . . . . . 26 100 5.3.2. CertRep Message Format . . . . . . . . . . . . . . . . 26 101 5.4. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 27 102 5.4.1. GetCRL Message format . . . . . . . . . . . . . . . . 27 103 5.4.2. CertRep Message Format . . . . . . . . . . . . . . . . 27 104 5.5. Get Certificate Authority Certificate . . . . . . . . . . 28 105 5.5.1. GetCACert HTTP Message Format . . . . . . . . . . . . 28 106 5.5.2. Response . . . . . . . . . . . . . . . . . . . . . . . 28 107 5.5.2.1. CA Certificate Only Response . . . . . . . . . . . 28 108 5.5.2.2. CA and RA Certificates Response . . . . . . . . . 29 109 5.5.3. Get Next Certificate Authority Certificate . . . . . . 29 110 5.5.3.1. GetNextCACert HTTP Message Format . . . . . . . . 29 111 5.5.3.2. GetCACaps HTTP Message Format . . . . . . . . . . 29 112 5.6. Get Certificate Authority Certificate Chain . . . . . . . 29 113 5.6.1. GetCACertChain HTTP Message Format . . . . . . . . . . 29 114 5.6.2. Response . . . . . . . . . . . . . . . . . . . . . . . 29 115 5.6.3. Backwards Compatibility . . . . . . . . . . . . . . . 30 116 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 119 8.1. General Security . . . . . . . . . . . . . . . . . . . . . 30 120 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 30 121 8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 31 122 8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 31 123 8.5. Unnecessary cryptography . . . . . . . . . . . . . . . . . 31 124 9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 32 125 10. Normative References . . . . . . . . . . . . . . . . . . . . . 32 126 Appendix A. Cisco Requester Subject Name Definition . . . . . . . 33 127 Appendix B. IPSEC Client Enrollment Certificate Request . . . . . 33 128 Appendix C. Private OID Definitions . . . . . . . . . . . . . . . 35 129 Appendix D. CRL Query by means of LDAP . . . . . . . . . . . . . 35 130 Appendix E. SCEP State Transitions . . . . . . . . . . . . . . . 36 131 Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . . 39 132 Appendix G. Certificate Renewal and CA Key Rollover . . . . . . . 40 133 Appendix H. PKIOperation via HTTP POST Message . . . . . . . . . 40 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 135 Intellectual Property and Copyright Statements . . . . . . . . . . 42 137 1. Introduction 139 Public key technology is widely available and increasingly widely 140 deployed. X.509 certificates serve as the basis for several 141 standards-based security protocols in the IETF, such as IKE [RFC2409] 142 and IKEv2 [RFC4306], and TLS [RFC4346]. When an X.509 certificate is 143 issued by other than the certificate subject (a self-issued 144 certificate), there typically is a need for a certificate management 145 protocol. Such a protocol enables a PKI client to request a 146 certificate, certificate renewal, or certificate revocation from a 147 Certification Authority. Often there also is a need for protocols to 148 request a certificate or cert status info, although these functions 149 are often provided by distinct protocols, e.g., LDAP for X509 150 [RFC4523] or OCSP [RFC2560]. 152 This specification defines a protocol, SCEP, for certificate 153 management and certificate and CRL queries in a closed environment. 154 While widely deployed, this protocol omits some certificate 155 management features, e.g., in-band certificate revocation 156 transactions, that can significantly enhance the security achieved in 157 a PKI. The IETF protocol suite currently includes two certificate 158 management protocols with more comprehensive functionality: CMP 159 [RFC4210] and Certificate Management over CMS [RFC5272]. Where 160 interoperability with the installed base of SCEP implementations is 161 required, implementers are encouraged to support a comprehensive 162 standards track certificate management protocol in addition to the 163 protocol defined in this specification. This implementation strategy 164 balances near term requirements for interoperability with longer term 165 security goals. 167 1.1. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 2. The Goal of SCEP 175 The goal of SCEP is to support the secure issuance of certificates to 176 network devices in a scalable manner, using existing technology 177 whenever possible. The protocol supports the following operations: 179 o CA and RA public key distribution 181 o Certificate enrollment 182 o Certificate query 184 o CRL query 186 Certificate and CRL access can be achieved by using the LDAP protocol 187 (as specified in Appendix D), or by using the query messages defined 188 in SCEP. The use of HTTP certificate and CRL access, and the support 189 of CDP as specified in [RFC5280], is outside the scope of this 190 document. In Section Section 2.1, we first define PKI entity types 191 as well as the properties of each entity type. In Section 192 Section 2.2, the PKI operations are described at functional level. 193 Section Section 2.3 describes the transaction behavior of each PKI 194 operations. The complete PKI messages are covered in Section 195 Section 5. 197 2.1. SCEP Entity Types 199 The entity types defined in SCEP are the "requester" type (i.e., 200 IPSEC clients), the Certificate Authority (CA) entity type, and the 201 Registration Authority entity type (RA). A requester is sometimes 202 called a "SCEP client" in the following. 204 2.1.1. Requesters 206 A requester is an entity whose name is defined in a certificate 207 subject name field and optionally, in SubjectAltName, a X.509 208 certificate V3 extension. As a requester, a SCEP client is 209 identified by a subject name consisting of the following naming 210 attributes: 212 o Fully qualified domain name, for example, Router.cisco.com, 214 o IP Address, 216 o Serial number, and/or 218 o x.500 distinguished name. 220 The fully qualified domain name is required for a requester that 221 intends to use the certificate with, for example, IKE [RFC2409]. The 222 IP address, serial number, and x.500 distinguished name are optional 223 name attributes. 225 In the certificate enrollment request, the PKCS#10 [RFC2986] subject 226 field contains the required and optional name attributes. The 227 distinguished name, if any, should be the subject name field, while 228 any domain name, serial number, or IP address supplied should be in 229 the subjectAltName field. The subjectName field may be empty (if 230 there is no distinguished name) or the subjectAltName may be omitted, 231 but not both. 233 It is important to note that a client named as Alice.cisco.com is 234 different than a client named as "Alice.cisco.com+192.0.2.4" (read 235 Alice.cisco.com plus the IP address name attribute 192.0.2.4). From 236 a CA point of view, the Distinguished names assigned in these two 237 cases are distinct names. 239 Entity names which are specified as in the IPSEC profile (i.e., FQDN, 240 IP address and User FQDN) must be presented in the certificate's 241 SubjectAltName extension. Multiple IPSEC entity names, (if any) are 242 encoded as multiple values of a single SubjectAltName extension. The 243 CA has the authority to assign a distinguished name to a requester, 244 whether or not one was included in the request. The assigned DN 245 should contain the SCEP client names as the relative DN. 247 The attribute identifiers and an example of SCEP client subject name 248 are specified in Appendix A. Appendix B has an example from Cisco 249 VPN Client enrollment request. 251 2.1.1.1. Local Key/Certificate/CRL Storage and Certificate-name 252 uniqueness 254 A requester is required to generate, and provide storage for, 255 asymmetric keypairs. If the requester does not have enough permanent 256 memory to save its certificate, then it should be able to query its 257 own certificate from the CA or an LDAP server, once the certificate 258 has been issued. 260 A keypair can be generated with a specific key usage. The key usage 261 is conveyed to the CA through the certificate enrollment request. 262 All current SCEP client implementations expect that there will be 263 only one keypair for a given subjectName and key usage combination 264 and CA, at any time. This property is called the certificate-name 265 uniqueness property, and it implies that a CA that implements SCEP 266 will enforce the unique mapping between a SCEP client subject name 267 and its keypairs with a given key usage. At any time, if the subject 268 name is changed, or if the keypair is updated, the existing 269 certificate would have to be revoked before a new one could be 270 issued. 272 It is desirable that the CA enforce certificate-name uniqueness, but 273 it is not mandatory. However a CA that does not enforce uniqueness 274 must provide some other mechanism to prevent the re-transmission of 275 an enrollment request by a SCEP client from creating a second 276 certificate or certificate request, nor can the second request merely 277 be rejected. If a client times out from polling for a pending 278 request it can resynchronize by reissuing the original request with 279 the original subject name, key, and transaction ID. This should 280 return the status of the original transaction, including the 281 certificate if it was granted. It should not create a new 282 transaction unless the original certificate has been revoked, or the 283 transaction arrives more than halfway through the validity time of 284 the original certificate. 286 An enrollment request that occurs more than halfway through the 287 validity time of an existing certificate for the same subjectName and 288 key usage MAY be interpreted as a re-enrollment or renewal request 289 and accepted. A new certificate with new validity dates may be 290 issued, even though the old one is still valid, if the CA policy 291 permits, as described in Section 2.1.1.3. See also Appendix G. 293 2.1.1.2. Requester authentication 295 As with every protocol that uses public-key cryptography, the 296 association between the public keys used in the protocol and the 297 identities with which they are associated must be authenticated in a 298 cryptographically secure manner. This requirement is needed to 299 prevent a "man in the middle" attack, in which an adversary can 300 manipulate the data as it travels between the protocol participants 301 and subvert the security of the protocol. 303 PKCS#10 [RFC2986] specifies the use of a ChallengePassword attribute 304 to be sent as part of the enrollment request. SCEP uses this 305 ChallengePassword to satisfy the above requirements for security. 306 The PKCS#7 [RFC2315] envelope protects the privacy of the challenge 307 password. 309 2.1.1.2.1. Manual enrollment authentication 311 In the manual mode, the requester is required to wait until its 312 identity can be verified by the CA operator using any reliable out- 313 of-band method. To prevent a "man-in-the-middle" attack, a SHA-1, 314 SHA-256, SHA-512, or MD5 `fingerprint' generated on the PKCS#10 315 [RFC2986] (before PKCS#7 [RFC2315] enveloping and signing) SHOULD be 316 compared out-of-band between the CA operator and the requester. SCEP 317 clients and CAs (or RAs, if appropriate) MUST display this 318 fingerprint to the operator to enable this verification if manual 319 mode is used. Failing to provide this information leaves the 320 protocol vulnerable to attack by sophisticated adversaries. 322 In this case the challenge password is only used to authenticate a 323 request for the certificate's revocation. 325 2.1.1.2.2. Automated enrollment authentication 327 When utilizing a pre-shared secret scheme, the server should 328 distribute a shared secret to the requester which can uniquely 329 associate the enrollment request with the given end entity. The 330 distribution of the secret must be private: only the end entity 331 should know this secret. The actual binding mechanism between the 332 requester and the secret is subject to the server policy and 333 implementation. 335 When using the pre-shared secret scheme, the requester must enter the 336 pre-distributed secret as the ChallengePassword. It can then also be 337 used to authenticate a request for the certificate's revocation. 339 2.1.1.3. Requester Uses Existing CA-Issued or Self-Signed Certificates 341 In this protocol, the communication between the requester and the 342 certificate authority is secured by using PKCS#7 [RFC2315] as the 343 messaging protocol (see Section 4). PKCS#7 [RFC2315], however, is a 344 data format which assumes the communicating entities already possess 345 the peer's certificates and requires both parties use the issuer 346 names and issuer assigned certificate serial numbers to identify the 347 certificate in order to verify the signature and decrypt the message. 349 o If the requesting system already has a certificate issued by the 350 CA, that certificate SHOULD be presented as credentials for the 351 renewal of that certificate if the CA supports the "Renewal" 352 capability and the CA policy permits the certificate to be 353 renewed. 355 o If the requesting system has no certificate issued by the CA, but 356 has credentials from a different CA, that certificate MAY be 357 presented as credentials instead of a self-signed certificate. 358 Policy settings on the SCEP server will determine if the request 359 can be accepted or not. 361 o If the requester does not have an appropriate existing 362 certificate, then a self signed certificate must be used instead. 363 The self signed certificate MUST use the same subjectName as in 364 the pkcs10 request. 366 During the certificate enrollment, the requester will attach the 367 appropriate certificate to the signed certificate request. 369 When the Certificate Authority creates the PKCS#7 envelope on the 370 issued certificate, it should use the public key, issuer name, and 371 serial number conveyed in the above included certificate (from the 372 SignerInfo section of the inner pkcs#7 of the request). This will 373 inform the end entity on which private key should be used to open the 374 envelope. Note that when a client enrolls for separate encryption 375 and signature certificates, it may use the signature certificate to 376 sign both requests, and then expect its signature key to be used to 377 encrypt both responses. 379 In any case, the recipientInfo on the envelope should reflect the key 380 used to encrypt the request. 382 2.1.1.4. Trusted CA Store 384 To support interoperability between IPSEC peers whose certificates 385 are issued by different CAs, SCEP allows the users to configure 386 multiple trusted certificates. Trusted certificates are configured 387 as such in the client, based on some out-of-band means such as a 388 "fingerprint". These trusted certificates are used to verify 389 certificate chains that end in those certificates. 391 2.1.2. Certificate Authority 393 A Certificate Authority(CA) is an entity whose name is defined in the 394 certificate issuer name field. Before any PKI operations can begin, 395 the CA generates its own public key pair and creates a self-signed CA 396 certificate, or causes another CA to issue a certificate to it. 397 Associated with the CA certificate is a fingerprint which will be 398 used by the requester to authenticate the received CA certificate if 399 it is self-signed. The fingerprint is created by calculating a 400 SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate. 401 Before any requester can start its enrollment, this CA certificate 402 has to be configured at the entity side securely. For IPSEC clients, 403 the client certificates must have SubjectAltName extension. To 404 utilize LDAP as a CRL query protocol, the certificates must have a 405 CRL Distribution Point. Key usage is optional. Without key usage, 406 the public key is assumed as a general purpose public key and it can 407 be used for all purposes. 409 A Certificate Authority may enforce certain name policy. When using 410 a X.500 directory name as the subject name, all the name attributes 411 specified in the PKCS#10 [RFC2986] request should be included as 412 Relative DN. All the name attributes as defined in [RFC5280] should 413 be specified in the SubjectAltName. An example is provided in 414 Appendix A. 416 If there is no LDAP or HTTP query protocol support, the Certificate 417 Authority itself should answer certificate and CRL queries, and to 418 this end it should be online all the time. 420 The updating of the CA's public key is addressed in Appendix G. 422 2.1.3. Registration Authorities 424 In an environment where an RA is present, a requester performs 425 enrollment through the RA. In order to setup a secure channel with 426 an RA using PKCS#7 [RFC2315], the RA certificate(s) have to be 427 obtained by the client in addition to the CA certificate(s). 429 In the following, the CA and RA are specified as one entity in the 430 context of PKI operation definitions. 432 2.2. SCEP Operations Overview 434 In this section, we give a high level overview of the PKI operations 435 as defined in SCEP. 437 2.2.1. Requester Initialization 439 The requester initialization includes the key pair generation and the 440 configuring of the required information to communicate with the 441 certificate authority. 443 2.2.1.1. RSA Key Pairs 445 Before a requester can start a PKI transaction, it must have at least 446 one RSA key pair. 448 Key pairs may be intended for particular purposes, such as encryption 449 only, or signing only. The usage of any associated certificate can 450 be restricted by adding key usage and extended key usage attributes 451 to the PKCS#10 [RFC2986]. 453 2.2.1.2. non-RSA Keys 455 SCEP does not support non-RSA keys. Though the protocol (being based 456 on PKCS#7) does not preclude them, RSA is the only algorithm 457 supported by current implementations. 459 2.2.1.3. Required Information 461 A requester is required to have the following information configured 462 before starting any PKI operations: 464 1. the certificate authority IP address or fully-qualified domain 465 name, 467 2. the certificate authority HTTP CGI script path, 468 3. the HTTP proxy information if there is no direct Internet 469 connection to the server, 471 4. If CRLs are being published by the CA to an LDAP directory 472 server, and there is a CRL Distribution Point containing only an 473 X.500 directory name, then the client will need to know the LDAP 474 server fully-qualified domain name or IP address. CRL 475 Distribution Points are discussed in more detail in [RFC5280]. 477 2.2.2. CA/RA Certificate Distribution 479 Before any PKI operation can be started, the requester needs to get 480 the CA/RA certificates. At this time, since no public key has been 481 exchanged between the requester and the CA/RA, the message to get the 482 CA/RA certificate cannot be secured using PKCS#7 [RFC2315]. Instead, 483 the CA/RA certificate distribution is implemented as a clear HTTP Get 484 operation. After the requester gets the CA certificate, it has to 485 authenticate the CA certificate by comparing the finger print with 486 the CA/RA operator out-of-band. Since the RA certificates are signed 487 by the CA, there is no need to authenticate the RA certificates. 489 This operation is defined as a transaction consisting of one HTTP Get 490 message and one HTTP Response message: 491 REQUESTER CA SERVER 492 Get CA/RA Certificate: HTTP Get message 493 -----------------------------> 494 CA/RA Certificate download: HTTP Response message 495 <--------------------------------------- 496 Compute finger print and 497 call CA operator. 498 Receive call and check finger print 500 Get CA/RA Certificate 502 If an RA is in use, a degenerated PKCS#7 [RFC2315] with a certificate 503 chain consisting of both RA and CA certificates is sent back to the 504 end entity. Otherwise the CA certificate is directly sent back as 505 the HTTP response payload. 507 2.2.3. Certificate Enrollment 509 A requester starts an enrollment transaction by creating a 510 certificate request using PKCS#10 [RFC2986] and sends it to the CA/RA 511 enveloped using the PKCS#7 [RFC2315]. After the CA/RA receives the 512 request, it will either automatically approve the request and send 513 the certificate back, or it will require the requester to wait until 514 the operator can manually authenticate the identity of the requester. 516 In the automatic mode, the transaction consists of one PKCSReq PKI 517 Message, and one CertRep PKI message. 519 In the manual mode, the requester enters into polling mode by 520 periodically sending a GetCertInitial PKI message to the server, 521 until the server operator completes the manual authentication, after 522 which the CA will respond to GetCertInitial by returning the issued 523 certificate. 525 It is up to local CA policy (and CA implementation) as to whether a 526 certificate is granted automatically, or whether it is manually 527 granted by the administrator. The ChallengePassword MAY be used to 528 automatically authenticate the request, but does not have to. 530 Polling mode is entered whenever the server returns a PENDING 531 response. 533 The transaction in automatic mode: 534 REQUESTER CA SERVER 536 PKCSReq: PKI cert. enrollment msg 537 --------------------------------> CertRep: pkiStatus = SUCCESS 538 certificate attached 539 <------------------------------ 540 Receive issued certificate. 542 The transaction in manual mode: 543 REQUESTER CA SERVER 544 PKCSReq: PKI cert. enrollment msg 545 --------------------------------> CertRep: pkiStatus = PENDING 546 <------------------------------ 547 GetCertInitial: polling msg 548 --------------------------------> CertRep: pkiStatus = PENDING 549 <------------------------------ 550 ................. CertRep: pkiStatus = SUCCESS 554 certificate attached 555 <------------------------------ 556 Receive issued certificate. 558 2.2.4. Requester Certificate Revocation 560 SCEP currently only allows revocation as an out-of-band process. In 561 order to revoke a certificate, the requester must contact the CA 562 server operator, who MAY wish to verify the ChallengePassword (which 563 has been sent to the server as an attribute of the PKCS#10 [RFC2986] 564 certificate request). If the ChallengePassword matches, the 565 certificate can be revoked. 567 2.2.5. Certificate Access 569 There are two methods to query certificates. The first method is to 570 use LDAP as a query protocol. Using LDAP to query assumes the client 571 understand the LDAP scheme supported by the CA. The SCEP client 572 assumes that the subject DN name in the certificate is used as the 573 URL to query the certificate. The standard attributes 574 (userCertificate and caCertificate) are used as filter. 576 For the environment where LDAP is not available, a certificate query 577 message is defined to retrieve the certificates from the CA. 579 To query a certificate from the certificate authority, a requester 580 sends a request consisting of the certificate's issuer name and the 581 serial number. This assumes that the requester has saved the issuer 582 name and the serial number of the issued certificate from the 583 previous enrollment transaction. The transaction to query a 584 certificate consists of one GetCert PKI message and one CertRep PKI 585 message: 586 REQUESTER CA SERVER 587 GetCert: PKI certificate query msg 588 -------------------------------> CertRep: pkiStatus = SUCCESS 589 certificate attached 590 <----------------------------- 591 Receive the certificate. 593 2.2.6. CRL Distribution 595 The CA/RA will not "push" the CRL to the end entities. The query of 596 the CRL can only be initialized by the requester. 598 There are two methods to query CRL: 600 1. If the CA supports CRL Distribution Points [RFC5280] (section 601 4.2.1.13), then the CRL MUST be retrieved via the mechanism 602 specified in the CDP. This is the preferred method. Please 603 refer to Appendix D for the examples of CRL Distribution Point. 605 2. If the CA does not support CDP's, a CRL query is composed by 606 creating a message consisting of the CA issuer name and the CA's 607 certificate serial number. This method is deprecated because it 608 does not scale well and requires the CA to be a high-availability 609 service. 611 The message is sent to the CA in the same way as the other SCEP 612 requests: The transaction to query CRL consists of one GetCRL PKI 613 message and one CertRep PKI message which contain only the CRL (no 614 certificates). 616 REQUESTER CA SERVER 617 GetCRL: PKI CRL query msg 618 ----------------------------------> 619 CertRep: CRL attached 620 <-------------------------------- 622 2.3. PKI Operation Transactional Behavior 624 As described before, a PKI operation is a transaction consisting of 625 the messages exchanged between a requester and the CA/RA. This 626 section will specify the transaction behavior on both the requester 627 and the certificate authority server. Because the protocol is 628 basically a two way communication protocol without a confirmation 629 message from the initiating side, state and state resynchronization 630 rules have to be defined, in case any error happens at either side. 631 Before the state transition can be defined, the notion of transaction 632 identifier has to be defined first. 634 2.3.1. Transaction Identifier 636 A transaction identifier is a string generated by the entity when 637 starting a transaction. Since all the PKI operations defined in this 638 protocol are initiated by the requester, it is the responsibility of 639 the requester to generate a unique string as the transaction 640 identifier. All the PKI messages exchanged for a given PKI 641 transaction must carry the same transaction identifier. 643 The transaction identifier is generated as a SHA-1, SHA-256, SHA-512 644 or MD5 hash on the public key value for which the enrollment request 645 is made. This allows the SCEP client to reuse the same transaction 646 identifier if it is reissuing a request for the same certificate 647 (i.e. a certificate with the same subject, issuer, and key). The 648 SCEP protocol requires that transaction identifiers be unique, so 649 that queries can be matched up with transactions. For this reason, 650 in those cases in which separate signing and encryption certificates 651 are issued to the same requester, the keys must be different. 653 2.3.2. State Transitions in Certificate Enrollment 655 The requester state transitions during enrollment operation are 656 indicated in the diagram below: 658 +-<------+ 659 | | 660 GetCertInitial triggered by timeout or 661 | | manual authentication 662 | | 663 [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] 664 | PKCSReq | CertRep with SUCCESS 665 | | 666 | | 667 +--------<-------------------+ 668 request rejected, timeout, or error 670 As described in the section 2.2.3, certificate enrollment starts at 671 the state CERT-NONEXISTANT. Sending PKCSReq changes the state to 672 CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the 673 state to CERT-ISSUED. In the case the server sending back the 674 response with pending status, the requester will keep polling 675 certificate response by sending GetCertInitial to the server, until 676 either a CertRep with SUCCESS status is received, or the maximum 677 polling number has been exceeded. 679 If an error or timeout occurs in the CERT-REQ-PENDING state, the end 680 entity will transition to the CERT-NONEXISTANT state. 682 The client administrator will, eventually, start up another 683 enrollment request. It is important to note that, as long as the 684 requester does not change its subject name or keys, the same 685 transaction id will be used in the "new" transaction. This is 686 important because based on this transaction id, the certificate 687 authority server can recognize this as an existing transaction 688 instead of a new one. 690 2.3.3. Transaction Behavior of Certificate/CRL Access 692 There is no state maintained during certificate access and CRL access 693 transaction. When using the certificate query and CRL query messages 694 defined in this protocol, the transaction identifier is still 695 required so that the requester can match the response message with 696 the upstanding request message. When using LDAP to query the 697 certificate and the CRL, the behavior is specified by the LDAP 698 protocol. 700 2.4. Security 702 The security goals of SCEP are that no adversary can: 704 o subvert the public key/identity binding from that intended, 706 o discover the identity information in the enrollment requests and 707 issued certificates, 709 o cause the revocation of certificates with any non-negligible 710 probability. 712 Here an adversary is any entity other than the requester and the CA 713 (and optionally the RA) participating in the protocol that is 714 computationally limited, but that can manipulate data during 715 transmission (that is, a man-in-the-middle). The precise meaning of 716 'computationally limited' depends on the implementer's choice of 717 cryptographic hash functions and ciphers. The required algorithms 718 are RSA, DES and MD5. Depending on the CA Capabilities, Triple-DES 719 may be used instead of DES, and SHA-1, SHA-256, or SHA-512 may be 720 used instead of MD5. [See Appendix F]. 722 The first and second goals are met through the use of PKCS#7 723 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures 724 using authenticated public keys. The CA's public key is 725 authenticated via the checking of the CA fingerprint, as specified in 726 Section 2.1.2, and the SCEP client's public key is authenticated 727 through the manual authentication or pre-shared secret 728 authentication, as specified in Section 2.1.1.2. The third goal is 729 met through the use of a Challenge Password for revocation, that is 730 chosen by the SCEP client and communicated to the CA protected by the 731 PKCS#7 [RFC2315] encryption, as specified in Section 2.2.4. 733 The motivation of the first security goal is straightforward. The 734 motivation for the second security goal is to protect the identity 735 information in the enrollment requests and certificates. For 736 example, two IPSEC hosts behind a firewall may need to exchange 737 certificates, and may need to enroll certificates with a CA that is 738 outside of a firewall. 740 Most networks with firewalls seek to prevent IP addresses and DNS 741 information from the trusted network leaving that network. The 742 second goal enables the hosts in this example to enroll with a CA 743 outside the firewall without revealing this information. The 744 motivation for the third security goal is to protect the SCEP clients 745 from denial of service attacks. 747 3. Transport Protocol 749 In the SCEP protocol, HTTP is used as the transport protocol for the 750 PKI messages. 752 3.1. HTTP "GET" and "POST" Message Format 754 The following is the syntax definition of a HTTP GET message sent 755 from a requester to a certificate authority server: 757 "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE 759 where: 761 o CGI-PATH defines the actual CGI path to invoke the CGI program 762 which parses the request. 764 o CGI-PROG is set to be the string "pkiclient.exe". This is 765 intended to be the program that the CA will use to handle the SCEP 766 transactions, though the CA may ignore CGI-PROG and use only the 767 CGI-PATH. 769 o OPERATION is set to be the string 771 o 773 * "PKIOperation" when the GET message carries a PKI message to 774 request certificates or CRL 776 * "GetCACaps", "GetCACert", "GetNextCACert" or "GetCACertChain" 777 when the GET operation is used to get CA capabilities, CA/RA 778 certificate, the replacement CA/RA certificates for when the 779 current ones expire, or the CA Certificate chain (respectively) 781 o MESSAGE is 783 o 785 * a base64-encoded PKI message , when OPERATION is "PKIOperation" 786 and method is GET. 788 * a CRL distribution point in URI format , when OPERATION is 789 GetCRL, 791 * a string which represents the certificate authority issuer 792 identifier otherwise. 794 SCEP uses the HTTP "GET" and "POST" messages to request information 795 from the CA. Requests for CA certificates or capabilities are sent 796 in the clear, using "GET", with the OPERATION and MESSAGE fields 797 identifying the requested data. CRLs may also be requested in the 798 clear if the CA supports it. 800 Other types of requests are sent using the PKCS#7 [RFC2315] data 801 format. These may be issued by means of a GET operation with 802 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 803 identifies the type of GET operation, and MESSAGE is actually the 804 PKCS#7 [RFC2315] message Base64-Encoded. 806 For example. a requester may submit a message via HTTP to the server 807 as follows: 808 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D 809 QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 811 If supported by the CA, the message may also be sent via HTTP POST: 812 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 813 Content-Length: 1234 815 817 This is further described in Appendix H. To determine if the CA 818 supports POST, use the GetCACaps message described in Appendix F. 820 3.2. Response Message Format 822 For each GET operation, the CA/RA server will return a MIME object 823 via HTTP. For a GET operation with PKIOperation as its type, the 824 response is tagged as having a Content Type of application/ 825 x-pki-message. The body of this message is a BER encoded binary PKI 826 message. The following is an example of the response: 827 "Content-Type:application/x-pki-message\n\n" 829 In the case of GET operation with a type of GetCACert the MIME 830 content type returned will depend on whether or not an RA is in use. 831 If there is no RA, only the CA certificate is sent back in the 832 response, and the response has the content type tagged as 833 application/x-x509-ca-cert. The body of the response is a DER 834 encoded binary X.509 certificate. For example: 835 "Content-Type:application/x-x509-ca-cert\n\n" 837 If there is an RA, the RA certificates are sent back together with 838 the CA certificates, a certificate-only PKCS#7 [RFC2315] SignedData 839 is sent back in the response where the SignerInfo is empty. Section 840 5 has the detailed definition of the message format in this case. 841 The content type is application/x-x509-ca-ra-cert. 843 The response to GetNextCACert is always a certificates-only PKCS#7 844 [RFC2315] SignedData with a content type of application/ 845 x-x509-ca-ra-cert. If there is an RA, The signer is the current RA 846 certificate. Otherwise, the signer is the current CA certificate. 848 If the CA supports it, PKIOperation may also be done via an HTTP 849 POST. This is described in Appendix H. 851 4. Secure Transportation: PKCS#7 853 PKCS#7 [RFC2315] is a general enveloping mechanism that enables both 854 signed and encrypted transmission of arbitrary data. It is widely 855 implemented and included in the RSA tool kit. In this section, the 856 general PKCS#7 [RFC2315] enveloped PKI message format is specified. 858 All messages MUST be valid PKCS#7 [RFC2315] structures, unless 859 otherwise noted. 861 4.1. SCEP Message Format 863 An SCEP message consists of an information portion (which depends on 864 the type of SCEP message being sent) and a set of transaction- 865 specific Attributes (see section Section 4.2). 867 The message-specific information is used as EnvelopeContent in an 868 SCEP pkcsPKIEnvelope message (see section Section 4.1.1). 870 Next, the pkcsPKIEnvelope is used as Content for a pkiMessage SCEP 871 type (see section Section 4.1.2). 873 The transaction-specific attributes are encoded as a set of 874 authenticatedAttributes in the SignerInfo of the SignedData. 876 By applying both enveloping and signing transformations, a SCEP 877 message is protected both for the integrity of its end-end-transition 878 information and the confidentiality of its information portion. The 879 advantage of this technique over the conventional transaction message 880 format is that, the signed transaction type information and the 881 status of the transaction can be determined prior to invoke security 882 handling procedures specific to the information portion being 883 processed. 885 4.1.1. SCEP pkcsPKIEnvelope 887 The SCEP messages are carried inside an Enveloped-data content type, 888 as defined in PKCS#7 Section 10, with the following restrictions: 890 o version shall be 0 892 o EncryptedContent shall be the SCEP message being transported (see 893 section Section 5) 895 The message is encrypted using the public key of the recipient, i.e. 896 the RA or the CA the message is for. 898 NOTE: The PKCS#7 [RFC2315] EncryptedContent is specified as an octet 899 string, but SCEP entities must also accept a sequence of octet 900 strings as a valid alternate encoding. 902 4.1.2. SCEP pkiMessage type 904 A SCEP pkiMessage consists of an Signed-data content type, as defined 905 in PKCS#7 Section 9. The following restrictions apply: 907 o version shall be 1 909 o The signed content shall be a pkcsPKIEnvelope 911 o The SignerInfo MUST contain a set of authenticatedAttributes (see 912 PKCS#7 Section 9.2 as well as section Section 4.2 in this 913 document. All messages are required to contain a SCEP 914 transactionID attribute, an SCEP messageType, and, of course, any 915 attributes required by PKCS#7 section 9.2. It may have other 916 attributes as well, depending on the messageType. 918 The message is signed in one of two ways: The requester can generate 919 a self-signed certificate, or the requester can use a previously 920 issued certificate, if the RA/CA supports the RENEWAL option. 922 4.2. Signed Transaction Attributes 924 The following transaction attributes are encoded as authenticated 925 attributes, and are carried, as specified in PKCS#7 Section 9.2, in 926 the SignerInfo for this signedData. 928 Please refer to Appendix B for the OID definitions. 930 +----------------+-----------------+---------------------------+ 931 | Attribute | Encoding | Comment | 932 +----------------+-----------------+---------------------------+ 933 | transactionID | PrintableString | Decimal value as a string | 934 | messageType | PrintableString | Decimal value as a string | 935 | pkiStatus | PrintableString | Decimal value as a string | 936 | failInfo | PrintableString | Decimal value as a string | 937 | senderNonce | OctetString | | 938 | recipientNonce | OctetString | | 939 +----------------+-----------------+---------------------------+ 941 The attributes are detailed in the following sections. 943 4.2.1. transactionID 945 The transactionID is an attribute which uniquely identifies a 946 transaction. This attribute is required in all PKI messages. 948 Because the enrollment transaction could be interrupted by various 949 errors, including network connection errors or client reboot, the 950 SCEP client generates a transaction identifier by calculating a hash 951 on the public key value for which the enrollment is requested. This 952 retains the same transaction identifier throughout the enrollment 953 transaction, even if the client has rebooted or timed out, and issues 954 a new enrollment request for the same key pair. 956 It also provides the way for the CA to uniquely identify a 957 transaction in its database. At the requester side, it generates a 958 transaction identifier which is included in PKCSReq. If the CA 959 returns a response of PENDING, the requester will poll by 960 periodically sending out GetCertInitial with the same transaction 961 identifier until either a response other than PENDING is obtained, or 962 the configured maximum time has elapsed. 964 For non-enrollment message (for example GetCert and GetCRL), the 965 transactionID should be a number unique to the client. 967 4.2.2. messageType 969 The messageType attribute specify the type of operation performed by 970 the transaction. This attribute is required in all PKI messages. 971 Currently, the following message types are defined: 973 o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request 975 o CertRep (3) -- Response to certificate or CRL request 977 o GetCertInitial (20) -- Certificate polling in manual enrollment 979 o GetCert (21) -- Retrieve a certificate 981 o GetCRL (22) -- Retrieve a CRL 983 4.2.3. pkiStatus 985 All response message will include transaction status information 986 which is defined as pkiStatus attribute: 988 o SUCCESS (0) -- request granted 989 o FAILURE (2) -- request rejected. This also requires a failInfo 990 attribute to be present, as defined in section 4.2.4. 992 o PENDING (3) -- request pending for manual approval 994 4.2.4. failInfo 996 The failInfo attribute will contain one of the following failure 997 reasons: 999 o badAlg (0) -- Unrecognized or unsupported algorithm ident 1001 o badMessageCheck (1) -- integrity check failed 1003 o badRequest (2) -- transaction not permitted or supported 1005 o badTime (3) -- Message time field was not sufficiently close to 1006 the system time 1008 o badCertId (4) -- No certificate could be identified matching the 1009 provided criteria 1011 4.2.5. senderNonce and responderNonce 1013 The attributes of senderNonce and recipientNonce are the 16 byte 1014 random numbers generated for each transaction to prevent the replay 1015 attack. 1017 When a requester sends a PKI message to the server, a senderNonce is 1018 included in the message. After the server processes the request, it 1019 will send back the requester senderNonce as the recipientNonce and 1020 generates another nonce as the senderNonce in the response message. 1021 Because the proposed PKI protocol is a two-way communication 1022 protocol, it is clear that the nonce can only be used by the 1023 requester to prevent the replay. The server has to employ extra 1024 state related information to prevent a replay attack. 1026 5. SCEP Transaction Specification 1028 In this section each SCEP transaction is specified in terms of the 1029 complete messages exchanged during the transaction. 1031 5.1. Certificate Enrollment 1033 The certificate enrollment transaction consists of one PKCSReq 1034 message sent to the certificate authority from a requester, and one 1035 CertRep message sent back from the server. 1037 Precondition: Both the requester and the certificate authority have 1038 completed their initialization process. The requester has already 1039 been configured with the CA/RA certificate. 1041 Postcondition: Either the certificate is received by the requester, 1042 or the end entity is notified to do the manual authentication, or the 1043 request is rejected. 1045 5.1.1. PKCSReq Message Format 1047 A PKCSReq message is a pkiMessage (see section Section 4.1.2), with 1048 the messageType attribute set to PKCSReq. 1050 The information portion of the pkiMessage is a PKCS#10 [RFC2986] 1051 certificate request, which MUST contain at least the following items: 1053 o the subject Distinguished Name 1055 o the subject public key 1057 o a ChallengePassword attribute. The Challenge Password may be used 1058 to (out-of-band) authenticate the enrollment request itself, or in 1059 an out-of-band revocation request for the issued certificate. 1061 Of course the certificate request may also contain any additional 1062 fields that make up a valid PKCS#10 request, including but not 1063 limited to an ExtensionReq attribute which is a sequence of 1064 extensions the requester expects to be included in its V3 certificate 1065 extensions (for example key-usage and extended key-usages). 1067 This pkiMessage of type PKCSReq MUST contain: 1069 o A transactionID attribute, calculated as per section Section 4.2.1 1071 o a messageType attribute set to PKCSReq 1073 o a senderNonce, calculated as per section Section 4.2.5 1075 The pkiMessage is then encrypted into a pkcsPKIEnvelope message (see 1076 section Section 4.1.1). 1078 5.1.2. CertRep Message Format 1080 The response to an SCEP enrollment request (PKCSReq) is a CertRep 1081 message. 1083 If the request is granted, the pkiStatus is set to SUCCESS, and the 1084 certificate is returned. 1086 If the request is rejected, the pkiStatus is set to FAILURE, and a 1087 failInfo attribute is returned. 1089 If the server requires manual approval of the request, the pkiStatus 1090 is set to PENDING. 1092 5.1.2.1. PENDING Response 1094 When the CA is configured to manually authenticate the requester, the 1095 CertRep is returned with the attribute pkiStatus set to PENDING. The 1096 data portion for this message is null. In addition to the attributes 1097 required by PKCS#7, the following SCEP attributes are required: 1099 o messageType set to CertReq 1101 o transactionID copied from the PKCSReq message 1103 o pkiStatus set to PENDING 1105 o senderNonce as defined in section Section 4.2.5 1107 o recipientNonce as defined in section Section 4.2.5 1109 5.1.2.2. FAILURE Response 1111 In this case, the CertRep sent back to the requester is same as in 1112 the PENDING case, except that the pkiStatus attribute is set to 1113 FAILURE, and the failInfo attribute should be included. 1115 5.1.2.3. SUCCESS response 1117 In this case, the information portion of CertRep will be a 1118 degenerated PKCS#7 [RFC2315] which contains the requester's newly 1119 generated certificate. The CertRep is otherwise identical to the 1120 PENDING reply, with the exception that pkiStatus is set to SUCCESS. 1122 5.2. Poll for Requester Initial Certificate 1124 Either triggered by the PENDING status received from the CertRep, or 1125 by the non-response timeout for the previous PKCSReq, a requester 1126 will enter the polling state by periodically sending GetCertInitial 1127 to the server, until either the request is granted and the 1128 certificate is sent back, or the request is rejected, or the 1129 configured time limit for polling is exceeded. 1131 Since GetCertInitial is part of the enrollment, the messages 1132 exchanged during the polling period should carry the same 1133 transactionID attribute as the previous PKCSReq. 1135 PreCondition: Either the requester has received a CertRep with 1136 pkiStatus set to PENDING, or waiting for a previous PKCSReq has timed 1137 out. 1139 PostCondition: The requester has either received a valid response, 1140 which could be either a valid certificate (pkiStatus == SUCCESS), or 1141 a FAILURE message, or the polling period times out. 1143 5.2.1. GetCertInitial Message Format 1145 Since at this time the certificate has not been issued, the requester 1146 can only use the requester's subject name (which was contained in the 1147 original PKCS#10 sent via PKCSReq), combined with the transactionID 1148 attribute, to identify the polled certificate request. 1150 The certificate authority server must be able to uniquely identify 1151 the polled certificate request. A subject name can have more than 1152 one outstanding certificate request (with different key usage 1153 attributes). 1155 The content of the pkiMessage with messageType GetCertInitial is an 1156 ASN.1 issuerAndSubject type (see figure Figure 1). 1158 In addition to the authenticatedAttributes required for a valid 1159 PKCS#7, the pkiMessage MUST include the following: 1161 o messageType set to GetCertInitial 1163 o transactionID 1165 o senderNonce 1167 issuerAndSubject 1168 issuerAndSubject ::= SEQUENCE { 1169 issuer Name, 1170 subject Name 1171 } 1173 Figure 1 1175 5.2.2. GetCertInitial Response Message Format 1177 The response messages for GetCertInitial are the same as for PKCSReq. 1179 5.3. Certificate Access 1181 The certificate query message defined in this section is an option 1182 when the LDAP server is not available to provide the certificate 1183 query. A requester should be able to query an issued certificate 1184 from the certificate authority, as long as the issuer name and the 1185 issuer assigned certificate serial number is known to the requesting 1186 end entity. This transaction is not intended to provide the service 1187 as a certificate directory service. A more complicated query 1188 mechanism would have to be defined in order to allow a requester to 1189 query a certificate using various different fields. 1191 This transaction consists of one GetCert message sent to the server 1192 by a requester, and one CertRep message sent back from the server. 1194 PreCondition: The queried certificate have been issued by the 1195 certificate authority and the issuer assigned serial number is known. 1197 PostCondition: Either the certificate is sent back or the request is 1198 rejected. 1200 5.3.1. GetCert Message Format 1202 The queried certificate is identified by its issuer name and the 1203 issuer assigned serial number. If this is a query for an arbitrary 1204 requester's certificate, the requesting requester should includes its 1205 own CA issued certificate in the signed envelope. If this is a query 1206 for its own certificate (assume the requester lost the issued 1207 certificate, or does not have enough non-volatile memory to save the 1208 certificate), then the self-signed certificate has to be included in 1209 the signed envelope. 1211 The content of the pkiMessage with messageType GetCert is an ASN.1 1212 IssuerAndSerial type, as specified in PKCS#7 Section 6.7. 1214 In addition to the authenticatedAttributes required for a valid 1215 PKCS#7, the pkiMessage MUST include the following: 1217 o messageType set to GetCert 1219 o transactionID 1221 o senderNonce 1223 5.3.2. CertRep Message Format 1225 In this case, the CertRep from the server is same as the CertRep for 1226 the PKCSReq, except that the server will only either grant the 1227 request (SUCCESS) or reject the request (FAILURE). 1229 Also, the recipientInfo should use the CA issuer name and CA assigned 1230 serial number to identify the requester's key pair since at this 1231 time, the requester has received its own certificate. 1233 5.4. CRL Access 1235 The CRL query message defined in this section is an option when the 1236 LDAP server is not available to provide the CRL query. In the PKI 1237 protocol proposed here, only the requester can initiate the 1238 transaction to download CRL. 1240 A requester sends GetCRL request to the server and the server sends 1241 back CertRep whose information portion is a degenerated PKCS#7 1242 [RFC2315] which contains only the most recent CRL. The size of CRL 1243 included in the CertRep should be determined by the implementation. 1245 When a CRLDistributionPoint is used, the GetCRL exchange should not 1246 be used. Instead, the CRLDistributionPoint, as set in the 1247 certificate, should be queried (see [RFC5280] section 4.2.1.14). 1249 PreCondition: The certificate authority certificate has been 1250 downloaded to the end entity. 1252 PostCondition: CRL sent back to the requester. 1254 5.4.1. GetCRL Message format 1256 The CRL is identified by using both CA's issuer name and the CA 1257 certificate's serial number, combined into an ASN.1 1258 issuerAndSerialNumber type, as defined in PKCS#7 Section 6.7. This 1259 constitutes the content of the pkiMessage with messageType GetCRL. 1261 In addition to the authenticatedAttributes required for a valid 1262 PKCS#7, the pkiMessage MUST include the following: 1264 o messageType set to GetCRL 1266 o transactionID 1268 o senderNonce 1270 5.4.2. CertRep Message Format 1272 The CRL is sent back to the requester through CertRep message. The 1273 information portion of this message is a degenerated PKCS#7 [RFC2315] 1274 SignedData which contains only the raw DER encoded CRL. 1276 5.5. Get Certificate Authority Certificate 1278 To get the CA certificate, the requester does a "HTTP GET" with a URL 1279 that identifies a CGI script on the server and an optional CA issuer 1280 identifier as the parameter to the CGI script. 1282 The response is either a single X.509 CA certificate ("CA mode"), or 1283 a PKCS7 message containing the CA certificate and RA certificates 1284 ("RA mode"). The client can determine which mode the CA operates in 1285 by which response it gets. 1287 Once the CA certificate is received by the requester, a fingerprint 1288 is generated using the SHA1, SHA256, SHA512 or MD5 hash algorithm on 1289 the whole CA certificate. If the requester does not have a 1290 certificate path to a trusted CA certificate, this fingerprint may be 1291 used to verify the certificate, by some positive out-of-band means, 1292 such as a phone call. 1294 5.5.1. GetCACert HTTP Message Format 1296 "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT 1298 where: 1300 o CGI-PATH defines the actual CGI path to invoke the CGI program 1301 which parses the request. 1303 o CGI-PROG is set to be the string "pkiclient.exe" and this is 1304 expected to be the program that the CA will use to handle the SCEP 1305 transactions. 1307 o CA-IDENT is any string which is understood by the CA. For 1308 example, it could be a domain name like ietf.org. If a 1309 certificate authority has multiple CA certificates this field can 1310 be used to distinguish which is required. Otherwise it may be 1311 ignored. 1313 5.5.2. Response 1315 The response for GetCACert is different between the case where the CA 1316 directly communicated with the requester during the enrollment, and 1317 the case where a RA exists and the requester communicates with the RA 1318 during the enrollment. 1320 5.5.2.1. CA Certificate Only Response 1322 A binary X.509 CA certificate is sent back as a MIME object with a 1323 Content-Type of application/x-x509-ca-cert. 1325 5.5.2.2. CA and RA Certificates Response 1327 When an RA exists, both CA and RA certificates must be sent back in 1328 the response to the GetCACert request. The RA certificate(s) must be 1329 signed by the CA. A certificates-only PKCS#7 [RFC2315] SignedData is 1330 used to carry the certificates to the requester, with a Content-Type 1331 of application/x-x509-ca-ra-cert. 1333 5.5.3. Get Next Certificate Authority Certificate 1335 5.5.3.1. GetNextCACert HTTP Message Format 1337 "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA- 1338 IDENT 1340 The response to this message is a PKCS#7 [RFC2315] certificates-only 1341 message containing a CA certificate (and possibly RA certificates) to 1342 be used when the current CA certificate expires, signed with the 1343 current CA certificate (or RA certificate, if the CA is in RA mode. 1344 Note that a PKCS#7 [RFC2315] is returned even in CA mode. 1346 5.5.3.2. GetCACaps HTTP Message Format 1348 "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT 1350 This message requests capabilities from CA. The response is a list 1351 of text capabilities, as defined in Appendix F. Support for this 1352 message is optional, but if it is not supported, the client should 1353 assume that none of the capabilities in Appendix F are supported. 1355 5.6. Get Certificate Authority Certificate Chain 1357 GetCACertChain provides a way to get the entire certificate chain. 1359 5.6.1. GetCACertChain HTTP Message Format 1361 "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA- 1362 IDENT 1364 where: 1366 CGI-SCRIPT and CA-IDENT are as described for GetCACert. 1368 5.6.2. Response 1370 The response for GetCACertChain is a certificates-only PKCS#7 1371 [RFC2315] SignedData to carry the certificates to the requester, with 1372 a Content-Type of application/x-x509-ca-ra-cert-chain. 1374 5.6.3. Backwards Compatibility 1376 Versions of SCEP prior to revision 3 do not support GetCACertChain or 1377 GetNextCACert. Certificate Authorities written to these prior 1378 versions will not be able to process the message and may return an 1379 HTML error. 1381 To avoid this, clients should send the GetCACert message first. If 1382 the returned certificate is self-signed or is signed by a Certificate 1383 Authority that is trusted by the client, then it is not necessary to 1384 send the GetCACertChain message and it should not be sent. 1386 An old CA in a two-deep hierarchy might still get this message from a 1387 client if the client did not trust either that CA or its issuer. 1389 6. Acknowledgements 1391 The authors would like to thank Peter William of ValiCert, Inc. 1392 (formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and 1393 Christopher Welles of IRE, Inc. for their contributions to this 1394 protocol and to this document. 1396 7. IANA Considerations 1398 This memo includes no request to IANA. 1400 8. Security Considerations 1402 8.1. General Security 1404 Common key-management considerations such as keeping private keys 1405 truly private and using adequate lengths for symmetric and asymmetric 1406 keys must be followed in order to maintain the security of this 1407 protocol. 1409 This is especially true for CA keys, which, when compromised, 1410 compromise the security of all relying parties. 1412 8.2. Use of the CA keypair 1414 A CA keypair is generally meant for (and is usually flagged as) 1415 "certificate signing" (exclusively), rather than 'data signing' or 1416 'data encryption'. The SCEP protocol, however, uses the CA keypair 1417 indiscriminately to encrypt and sign PKCS#7 transport messages. This 1418 is generally considered undesirable, as this weakens the CA keypair 1419 over time (it is generally accepted that using any key weakens it 1420 over time, as it gives an attacker more data to work with). 1422 While the CA keypair can be generated with the 'data encryption' and 1423 'data signing' flags set, this is operationally not encouraged. It 1424 would make using the key as a PKCS#7 transport key 'legal', but the 1425 discussion from the previous paragraph still applies. 1427 A solution is to use RA keys to secure the SCEP transport (i.e. 1428 message signing and encrypting), which allows the CA keys to be used 1429 only for their intended purpose of "certificate signing". 1431 An RA can be implemented in two ways: physically separate or 1432 implicit. In the implicit case, the CA simply creates an extra 1433 keypair. A physically separate RA allows the CA to be inside the 1434 secure network, not accessible to hackers at all. 1436 8.3. ChallengePassword 1438 The ChallengePassword sent in the PKCS#10 enrollment request is 1439 signed (via inclusion in a pkiMessage) and encrypted (via inclusion 1440 in a pkcsPKIEnvelope). When saved by the CA, care should be taken to 1441 protect this password. 1443 If the ChallengePassword is used to automatically authenticate an 1444 enrollment request, it is recommend that some form of one-time 1445 password be used to minimize damage in the event the data is 1446 compromised. 1448 8.4. transactionID 1450 A well-written CA/RA will not rely on the transactionID to be correct 1451 or as specified in this document. Requesters with buggy software 1452 might add additional undetected duplicate requests to the CA's queue 1453 (or worse). A well-written CA/RA should never assume the data from a 1454 requester is well-formed. 1456 8.5. Unnecessary cryptography 1458 Some of the SCEP exchanges use signing and encryption operations that 1459 are not necessary. In particular the GetCert and GetCRL exchanges 1460 are encrypted and signed (in both directions), where simply signing 1461 the request would suffice (CRL's and Certificates, i.e. the 1462 respective responses, are already signed by the CA and can be 1463 verified by the recipient). 1465 This may affect performance and scalability of the CA which could be 1466 used as an attack vector on the CA (though not an anonymous one). 1468 The use of CDP's is recommended for CRL access, as well as other ways 1469 of retrieving certificates (LDAP, direct HTTP access, etc). 1471 9. Intellectual Property 1473 This protocol includes the optional use of Certificate Revocation 1474 List Distribution Point (CRLDP) technology, which is a patented 1475 technology of Entrust Technologies, Inc. (Method for Efficient 1476 Management of Certificate Revocation Lists and Update Information 1477 (U.S. Patent 5,699,431)). Please contact Entrust Technologies, Inc. 1478 (www.entrust.com) for more information on licensing CRLDP technology. 1480 10. Normative References 1482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1483 Requirement Levels", BCP 14, RFC 2119, March 1997. 1485 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 1486 Version 1.5", RFC 2315, March 1998. 1488 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1489 (IKE)", RFC 2409, November 1998. 1491 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1492 Adams, "X.509 Internet Public Key Infrastructure Online 1493 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1495 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1496 Request Syntax Specification Version 1.7", RFC 2986, 1497 November 2000. 1499 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1500 "Internet X.509 Public Key Infrastructure Certificate 1501 Management Protocol (CMP)", RFC 4210, September 2005. 1503 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1504 RFC 4306, December 2005. 1506 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1507 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1509 [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol 1510 (LDAP) Schema Definitions for X.509 Certificates", 1511 RFC 4523, June 2006. 1513 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1514 (CMC)", RFC 5272, June 2008. 1516 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1517 Housley, R., and W. Polk, "Internet X.509 Public Key 1518 Infrastructure Certificate and Certificate Revocation List 1519 (CRL) Profile", RFC 5280, May 2008. 1521 Appendix A. Cisco Requester Subject Name Definition 1523 The ip address and the FQDN of a SCEP client should be included in 1524 the V3 extension subjectAltName. When the subjectAltName extension 1525 attribute is present, both the subjectAltName fields and the 1526 subjectName field could have the IP address and the FQDN information. 1528 When the X.500 directory is used by the CA to define the name space, 1529 the subject name defined above become a RDN which is part of DN bound 1530 to the requester's public key in the certificate. A sample of DN 1531 assigned by Entrust CA is given below (assume the same 1532 ciscoRouterAlice is used as the requester defined subject name): 1533 OU = InteropTesting, O = Entrust Technologies, C = CA 1534 RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} 1536 Appendix B. IPSEC Client Enrollment Certificate Request 1538 The following is the certificate enrollment request (PKCS#10 1539 [RFC2986]) as created by Cisco VPN Client: 1540 -----END NEW CERTIFICATE REQUEST----- 1541 0 30 439: SEQUENCE { 1542 4 30 288: SEQUENCE { 1543 8 02 1: INTEGER 0 1544 11 30 57: SEQUENCE { 1545 13 31 55: SET { 1546 15 30 53: SEQUENCE { 1547 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 1548 22 13 46: PrintableString 1549 : 'For Xiaoyi, IPSEC attrs in alternate name 1550 extn' 1551 : } 1552 : } 1553 : } 1554 70 30 158: SEQUENCE { 1555 73 30 13: SEQUENCE { 1556 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1557 1 1) 1558 86 05 0: NULL 1559 : } 1561 88 03 140: BIT STRING 0 unused bits 1562 : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E 1563 : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 1564 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 1565 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 1566 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F 1567 : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA 1568 : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 1569 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 1570 : [ Another 11 bytes skipped ] 1571 : } 1572 231 A0 63: [0] { 1573 233 30 61: SEQUENCE { 1574 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 1575 14) 1576 246 31 48: SET { 1577 248 30 46: SEQUENCE { 1578 250 30 44: SEQUENCE { 1579 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 1580 257 04 37: OCTET STRING 1581 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 1583 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 1584 6E 2E 69 72 65 2E 63 6F 6D 1585 : } 1586 : } 1587 : } 1588 : } 1589 : } 1590 : } 1592 296 30 13: SEQUENCE { 1593 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1594 1 1 4) 1595 309 05 0: NULL 1596 : } 1597 311 03 129: BIT STRING 0 unused bits 1598 : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A 1599 : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 1600 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 1601 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D 1602 : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 1603 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 1604 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 1605 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 1606 : } 1608 Appendix C. Private OID Definitions 1610 The OIDs used in SCEP are VeriSign self-maintained OIDs. 1612 +-------------------+-----------------------------------------------+ 1613 | Name | ASN.1 Definition | 1614 +-------------------+-----------------------------------------------+ 1615 | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | 1616 | | VeriSign(113733)} | 1617 | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | 1618 | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | 1619 | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | 1620 | | messageType(2)} | 1621 | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | 1622 | | pkiStatus(3)} | 1623 | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | 1624 | | failInfo(4)} | 1625 | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1626 | | senderNonce(5)} | 1627 | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | 1628 | | recipientNonce(6)} | 1629 | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | 1630 | | transId(7)} | 1631 | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | 1632 | | extensionReq(8)} | 1633 +-------------------+-----------------------------------------------+ 1635 Appendix D. CRL Query by means of LDAP 1637 In order to retrieve the CRL by means of LDAP, the client needs to 1638 know where in the directory it is stored. The certificate must 1639 contain a CRL Distribution Point extension encoded as a DN or as an 1640 LDAP URI. 1642 For example, the certificate issued by Entrust VPN contains the 1643 following DN as the CRL distribution point: 1644 CN = CRL1, O = cisco, C = US 1646 The ASN.1 encoding of this distribution point is: 1647 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 1648 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 1649 13 04 43 52 4C 31 1651 The ldap form would be: 1652 ldap://servername/CN=CRL1,O=cisco,C=US 1654 Appendix E. SCEP State Transitions 1656 SCEP state transitions are indexed by the transactionID attribute. 1657 The design goal is to ensure the synchronization between the CA and 1658 the requester under various error situations. An identity is defined 1659 by the combination of FQDN, the IP address and the client serial 1660 number. FQDN is the required name attribute. It is important to 1661 notice that, a client named as Alice.cisco.com is different from the 1662 client named as Alice.cisco.com plus IPAddress 192.0.2.4. 1664 Each enrollment transaction is uniquely associated with a transaction 1665 identifier (carried in the transactionID signed attribute (see 1666 section XXX). Because the enrollment transaction could be 1667 interrupted by various errors, including network connection errors or 1668 client reboot, the SCEP client generates a transaction identifier by 1669 calculating a hash on the public key value for which the enrollment 1670 is requested. This retains the same transaction identifier 1671 throughout the enrollment transaction, even if the client has 1672 rebooted or timed out, and issues a new enrollment request for the 1673 same key pair. It also provides the way for the CA to uniquely 1674 identify a transaction in its database. At the requester side, it 1675 generates a transaction identifier which is included in PKCSReq. If 1676 the CA returns a response of PENDING, the requester will poll by 1677 periodically sending out GetCertInitial with the same transaction 1678 identifier until either a response other than PENDING is obtained, or 1679 the configured maximum time has elapsed. 1681 If the client times out or the client reboots, the client 1682 administrator will start another enrollment transaction with the same 1683 key pair. The second enrollment will have the transaction 1684 identifier. At the server side, instead of accepting the PKCSReq as 1685 a new enrollment request, it should respond as if another 1686 GetCertInitial message had been sent with that transaction ID. In 1687 another word, the second PKCSReq should be taken as a 1688 resynchronization message to allow the enrollment resume as the same 1689 transaction. 1691 It is important to keep the transaction id unique since SCEP requires 1692 the same policy and same identity be applied to the same subject name 1693 and key pair binding. In the current implementation, an SCEP client 1694 can only assume one identity. At any time, only one key pair, with a 1695 given key usage, can be associated with the same identity. 1697 The following gives several examples of client to CA transactions. 1699 Client actions are indicated in the left column, CA actions are 1700 indicated in the right column. A blank action signifies that no 1701 message was received. Note that these examples assume that the CA 1702 enforces the certificate-name uniqueness property defined in 1703 Section 2.1.1.1. 1705 The first transaction, for example, would read like this: 1707 "Client Sends PKCSReq message with transaction ID 1 to the CA. The 1708 CA signs the certificate and constructs a CertRep Message containing 1709 the signed certificate with a transaction ID 1. The client receives 1710 the message and installs the certificate locally." 1712 Successful Enrollment Case: no manual authentication 1713 PKCSReq (1) ----------> CA Signs Cert 1714 Client Installs Cert <---------- CertRep (1) SIGNED CERT 1716 Successful Enrollment Case: manual authentication required 1717 PKCSReq (10) ----------> Cert Request goes into Queue 1718 Client Polls <---------- CertRep (10) PENDING 1719 GetCertInitial (10) ----------> Still pending 1720 Client Polls <---------- CertRep (10) PENDING 1721 GetCertInitial (10) ----------> Still pending 1722 Client Polls <---------- CertRep (10) PENDING 1723 GetCertInitial (10) ----------> Still pending 1724 Client Polls <---------- CertRep (10) PENDING 1725 GetCertInitial (10) ----------> Cert has been signed 1726 Client Installs Cert <---------- CertRep (10) SIGNED CERT 1728 Resync Case - CA Receive and Signs PKCSReq, Client Did not receive 1729 CertRep: 1730 PKCSReq (3) ----------> Cert Request goes into queue 1731 <---------- CertRep (3) PENDING 1732 GetCertInitial (3) ----------> 1733 <---------- CertRep (3) PENDING 1734 GetCertInitial (3) -----------> 1735 <----------- CA signed Cert and sent back 1736 CertRep(3) 1737 (Time Out) 1738 PKCSReq (3) ----------> Cert already signed, sent back to 1739 client 1740 Client Installs Cert <---------- CertRep (3) SIGNED CERT 1742 Case when NVRAM is lost and client has to generate a new key pair, 1743 there is no change of name information: 1745 PKCSReq (4) ----------> CA Signs Cert 1746 Client Installs Cert <---------- CertRep (4) SIGNED CERT 1747 (Client looses Cert) 1748 PKCSReq (5) ----------> There is already a valid cert with 1749 this DN. 1750 Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR 1751 PKCSReq (5) ----------> CA Signs Cert 1752 Client Installs Cert <---------- CertRep (5) SIGNED CERT 1753 Case when client admin resync the enrollment using a different PKCS#10: 1754 PKCSReq (6) ----------> CA Signs Cert 1755 <---------- CertRep (6) SIGNED CERT 1757 (Client timeout and admin starts another enrollment with a different 1758 PKCS#10, but the same transaction id) 1760 PKCSReq (6) with different PKCS#10 1761 ----------> There is already a valid cert with 1762 this entity (by checking FQDN). 1763 <---------- CertRep (6) INVALID PKCS#10 CERT 1764 ERROR 1766 Client admin either revokes the existing certificate or corrects the 1767 error by enrolling with the same PKCS#10 as the first PKCSReq(6) 1769 PKCSReq (6) ----------> CA find the existing Cert 1770 Client Installs Cert <---------- CertRep (6) SIGNED CERT 1771 Resync case when server is slow in response: 1772 PKCSReq (13) ----------> Cert Request goes into Queue 1773 <---------- CertRep (13) PENDING 1774 GetCertInitial ----------> Still pending 1775 <---------- CertRep (13) PENDING 1776 GetCertInitial ----------> Still pending 1777 <---------- CertRep (13) PENDING 1778 GetCertInitial ----------> Still pending 1779 <---------- CertRep (13) PENDING 1780 GetCertInitial ----------> Still pending 1781 (TimeOut) <---------- CertRep (13) PENDING 1782 * Case 1 1783 PKCSReq (13) ----------> Still pending 1784 Client polls <---------- CertRep (13) PENDING 1785 GetCertInitial ----------> Crete has been signed 1786 Client Installs Crete <---------- CertRep (13) SIGNED CERT 1787 * Case 2 1788 PKCSReq (13) ----------> Cert has been signed 1789 Client Installs Cert <---------- CertRep (13) SIGNED CERT 1791 Appendix F. CA Capabilities 1793 The response for a GetCACaps message is a list of CA capabilities, in 1794 plain text, separated by characters, as follows (quotation marks 1795 are NOT sent): 1797 +--------------------+----------------------------------------------+ 1798 | Keyword | Description | 1799 +--------------------+----------------------------------------------+ 1800 | "GetNextCACert" | CA Supports the GetNextCACert message. | 1801 | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | 1802 | | POST. | 1803 | "Renewal" | Clients may use current certificate and key | 1804 | | to authenticate an enrollment request for a | 1805 | | new certificate. | 1806 | "SHA-512" | CA Supports the SHA-512 hashing algorithm in | 1807 | | signatures and fingerprints. | 1808 | "SHA-256" | CA Supports the SHA-256 hashing algorithm in | 1809 | | signatures and fingerprints. | 1810 | "SHA-1" | CA Supports the SHA-1 hashing algorithm in | 1811 | | signatures and fingerprints. | 1812 | "DES3" | CA Supports triple-DES for encryption. | 1813 +--------------------+----------------------------------------------+ 1815 The client should use SHA-1, SHA-256, or SHA-512 in preference to MD5 1816 hashing if it is supported by the CA. 1818 A client MUST be able to accept and ignore any unknown keywords that 1819 might be sent back by a CA. 1821 If none of the above capabilities are supported by the CA, no data is 1822 returned. 1824 The appropriate HTML headers are returned in any case. 1826 Example: 1827 GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca 1829 might return: 1830 GetNextCACert POSTPKIOperation 1832 This means that the CA supports the GetNextCACert message and allows 1833 PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be 1834 sent using HTTP POST. 1836 Appendix G. Certificate Renewal and CA Key Rollover 1838 To renew a client certificate, use the PKCSreq message and sign it 1839 with the existing client certificate instead of a self-signed 1840 certificate. 1842 To obtain the new CA certificate prior to the expiration of the 1843 current one, use the GetNextCACert message if the CA supports it. 1845 To obtain a new client certificate signed by the new CA certificate, 1846 use the new CA or RA certificate in the message envelope. Example: 1847 GetNextCACert ----------> 1848 <---------- CertRep (3) New CA certificate 1850 PKCSReq* (1) ----------> CA Signs certificate with NEW key 1851 Client Stores Cert <---------- CertRep (3) Certificate issued 1852 for installation when from NEW CA certificate and keypair. 1853 existing cert expires. 1855 *enveloped for new CA or RA cert and keypair. The CA will use the 1856 envelope to determine which key and certificate to use to issue the 1857 client certificate. 1859 Appendix H. PKIOperation via HTTP POST Message 1861 If the remote CA supports it, any of the PKCS#7-encoded SCEP messages 1862 may be sent via HTTP POST instead of HTTP GET. This is allowed for 1863 any SCEP message except GetCACert, GetCACertChain, GetNextCACert, or 1864 GetCACaps. In this form of the message, Base 64 encoding is not 1865 used. 1866 POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 1867 Content-Length: 1869 1871 The client can verify that the CA supports SCEP messages via POST by 1872 looking for the "POSTPKIOperation" capability (See Appendix F). 1874 Authors' Addresses 1876 Andrew Nourse 1877 Cisco Systems, Inc. 1878 510 McCarthy Drive 1879 Milpitas, CA 1880 USA 1882 Email: nourse@cisco.com 1884 Xiaoyi Liu 1885 Cisco Systems, Inc. 1886 510 McCarthy Drive 1887 Milpitas, CA 1888 USA 1890 Email: xliu@cisco.com 1892 Jan Vilhuber (editor) 1893 Cisco Systems, Inc. 1894 510 McCarthy Drive 1895 Milpitas, CA 1896 USA 1898 Email: vilhuber@cisco.com 1900 Cheryl Madson 1901 Cisco Systems, Inc. 1902 510 McCarthy Drive 1903 Milpitas, CA 1904 USA 1906 Email: cmadson@cisco.com 1908 Full Copyright Statement 1910 Copyright (C) The IETF Trust (2008). 1912 This document is subject to the rights, licenses and restrictions 1913 contained in BCP 78, and except as set forth therein, the authors 1914 retain all their rights. 1916 This document and the information contained herein are provided on an 1917 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1918 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1919 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1920 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1921 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1922 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1924 Intellectual Property 1926 The IETF takes no position regarding the validity or scope of any 1927 Intellectual Property Rights or other rights that might be claimed to 1928 pertain to the implementation or use of the technology described in 1929 this document or the extent to which any license under such rights 1930 might or might not be available; nor does it represent that it has 1931 made any independent effort to identify any such rights. Information 1932 on the procedures with respect to rights in RFC documents can be 1933 found in BCP 78 and BCP 79. 1935 Copies of IPR disclosures made to the IETF Secretariat and any 1936 assurances of licenses to be made available, or the result of an 1937 attempt made to obtain a general license or permission for the use of 1938 such proprietary rights by implementers or users of this 1939 specification can be obtained from the IETF on-line IPR repository at 1940 http://www.ietf.org/ipr. 1942 The IETF invites any interested party to bring to its attention any 1943 copyrights, patents or patent applications, or other proprietary 1944 rights that may cover technology that may be required to implement 1945 this standard. Please address the information to the IETF at 1946 ietf-ipr@ietf.org.