Internet Engineering Task Force A. Nourse Internet-Draft Cisco Systems, Inc Intended status: Historic J. Vilhuber, Ed. Expires: October 3, 2009 Cisco Systems, Inc. April 2009 Cisco Systems' Simple Certificate Enrollment Protocol draft-nourse-scep-19 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by Nourse & Vilhuber Expires October 3, 2009 [Page 1] Internet-Draft SCEP April 2009 using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the enrollment protocol developed by VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. SCEP Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 2.1. SCEP Entities . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Requester . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1.1. Requester Initialization . . . . . . . . . . . . . 6 2.1.1.2. Trusted CA Store . . . . . . . . . . . . . . . . . 7 2.1.2. Certification Authority . . . . . . . . . . . . . . . 7 2.1.2.1. CA Certificate Fingerprint . . . . . . . . . . . . 8 2.1.2.2. Certification Authority Policies . . . . . . . . . 8 2.1.2.3. CRL's and CDP's . . . . . . . . . . . . . . . . . 8 2.1.2.4. Name Uniqueness . . . . . . . . . . . . . . . . . 8 2.1.2.5. Retransmission versus new request . . . . . . . . 8 2.1.2.6. Requester authentication . . . . . . . . . . . . . 9 2.1.3. Registration Authority . . . . . . . . . . . . . . . . 11 2.2. SCEP Functionality . . . . . . . . . . . . . . . . . . . . 11 2.2.1. CA/RA Certificate Distribution . . . . . . . . . . . . 11 2.2.2. Certificate Enrollment . . . . . . . . . . . . . . . . 12 2.2.2.1. State Transitions in Certificate Enrollment . . . 12 2.2.3. Certificate Access . . . . . . . . . . . . . . . . . . 14 2.2.4. CRL Access . . . . . . . . . . . . . . . . . . . . . . 15 2.2.5. Certificate Revocation . . . . . . . . . . . . . . . . 16 2.3. PKI Operation Transactional Behavior . . . . . . . . . . . 16 2.3.1. Transaction Identifier . . . . . . . . . . . . . . . . 16 2.3.2. Transaction Behavior of Certificate/CRL Access . . . . 16 2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. SCEP Secure Message Objects . . . . . . . . . . . . . . . . . 18 3.1. SCEP pkiMessage . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Signed Transaction Attributes . . . . . . . . . . . . 20 3.1.1.1. transactionID . . . . . . . . . . . . . . . . . . 20 3.1.1.2. messageType . . . . . . . . . . . . . . . . . . . 20 3.1.1.3. pkiStatus . . . . . . . . . . . . . . . . . . . . 21 3.1.1.4. failInfo . . . . . . . . . . . . . . . . . . . . . 21 3.1.1.5. senderNonce and responderNonce . . . . . . . . . . 21 3.1.1.6. signingTime Attribute . . . . . . . . . . . . . . 22 3.1.2. SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 22 3.2. SCEP pkiMessage types . . . . . . . . . . . . . . . . . . 22 3.2.1. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2. CertRep . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2.1. CertRep SUCCESS . . . . . . . . . . . . . . . . . 24 Nourse & Vilhuber Expires October 3, 2009 [Page 2] Internet-Draft SCEP April 2009 3.2.2.2. CertRep FAILURE . . . . . . . . . . . . . . . . . 24 3.2.2.3. CertRep PENDING . . . . . . . . . . . . . . . . . 24 3.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 25 3.2.3.1. IssuerAndSubject . . . . . . . . . . . . . . . . . 25 3.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Degenerate certificates-only PKCS#7 Signed-data . . . . . 26 4. SCEP Transactions . . . . . . . . . . . . . . . . . . . . . . 26 4.1. Get CA Certificate . . . . . . . . . . . . . . . . . . . . 27 4.1.1. Get CA Certificate Response Message Format . . . . . . 27 4.1.1.1. CA Certificate Response Message Format . . . . . . 27 4.1.1.2. CA/RA Certificate Response Message Format . . . . 27 4.2. Certificate Enrollment . . . . . . . . . . . . . . . . . . 27 4.2.1. Certificate Enrollment Response Message . . . . . . . 28 4.3. Poll for Requester Initial Certificate . . . . . . . . . . 28 4.3.1. Polling Response Message Format . . . . . . . . . . . 29 4.4. Certificate Access . . . . . . . . . . . . . . . . . . . . 29 4.4.1. Certificate Access Response Message Format . . . . . . 29 4.5. CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5.1. CRL Access Response Message Format . . . . . . . . . . 30 4.6. Get Next Certification Authority Certificate . . . . . . . 30 4.6.1. Get Next CA Response Message Format . . . . . . . . . 30 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 31 5.1. HTTP "GET" Message Format . . . . . . . . . . . . . . . . 31 5.1.1. Response Message Format . . . . . . . . . . . . . . . 31 5.2. SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . . 32 5.2.1. GetCACert . . . . . . . . . . . . . . . . . . . . . . 32 5.2.1.1. GetCACert Response . . . . . . . . . . . . . . . . 32 5.2.2. PKCSReq . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.2.1. PKCSReq Response . . . . . . . . . . . . . . . . . 33 5.2.3. GetCertInitial . . . . . . . . . . . . . . . . . . . . 33 5.2.3.1. GetCertInitial Response . . . . . . . . . . . . . 33 5.2.4. GetCert . . . . . . . . . . . . . . . . . . . . . . . 33 5.2.4.1. GetCert Response . . . . . . . . . . . . . . . . . 33 5.2.5. GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2.5.1. GetCRL Response . . . . . . . . . . . . . . . . . 34 5.2.6. GetNextCaCert . . . . . . . . . . . . . . . . . . . . 34 5.2.6.1. GetNextCACert Response . . . . . . . . . . . . . . 34 6. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8.1. General Security . . . . . . . . . . . . . . . . . . . . . 35 8.2. Use of the CA keypair . . . . . . . . . . . . . . . . . . 35 8.3. ChallengePassword . . . . . . . . . . . . . . . . . . . . 35 8.4. transactionID . . . . . . . . . . . . . . . . . . . . . . 36 8.5. Nonces and Replay . . . . . . . . . . . . . . . . . . . . 36 8.6. Key Usage Issues . . . . . . . . . . . . . . . . . . . . . 36 8.7. GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 36 Nourse & Vilhuber Expires October 3, 2009 [Page 3] Internet-Draft SCEP April 2009 8.8. Unnecessary cryptography . . . . . . . . . . . . . . . . . 37 8.9. GetNextCaCert . . . . . . . . . . . . . . . . . . . . . . 37 9. Intellectual Property . . . . . . . . . . . . . . . . . . . . 37 10. Normative References . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. IPSEC Client Enrollment Certificate Request . . . . . 38 Appendix B. Private OID Definitions . . . . . . . . . . . . . . . 40 Appendix C. SCEP State Transitions . . . . . . . . . . . . . . . 40 Appendix D. CA Capabilities . . . . . . . . . . . . . . . . . . . 43 D.1. GetCACaps HTTP Message Format . . . . . . . . . . . . . . 43 D.2. CA Capabilities Response Format . . . . . . . . . . . . . 43 Appendix E. Certificate Renewal and CA Key Rollover . . . . . . . 44 Appendix F. PKIOperation via HTTP POST Message . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Nourse & Vilhuber Expires October 3, 2009 [Page 4] Internet-Draft SCEP April 2009 1. Introduction Public key technology is widely available and increasingly widely deployed. X.509 certificates serve as the basis for several standards-based security protocols in the IETF, such as IKE [RFC2409] and IKEv2 [RFC4306], and TLS [RFC4346]. When an X.509 certificate is issued by other than the certificate subject (a self-issued certificate), there typically is a need for a certificate management protocol. Such a protocol enables a PKI client to request a certificate, certificate renewal, or certificate revocation from a certification authority. Often there also is a need for protocols to request a certificate or certificate status information, although these functions are often provided by distinct protocols. This specification defines a protocol, SCEP, for certificate management and certificate and CRL queries in a closed environment. While widely deployed, this protocol omits some certificate management features, e.g., in-band certificate revocation transactions, that can significantly enhance the security achieved in a PKI. The IETF protocol suite currently includes two certificate management protocols with more comprehensive functionality: CMP [RFC4210] and Certificate Management over CMS [RFC5272]. Where interoperability with the installed base of SCEP implementations is required, implementers are encouraged to support a comprehensive standards track certificate management protocol in addition to the protocol defined in this specification. This implementation strategy balances near term requirements for interoperability with longer term security goals. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. SCEP Protocol Overview The goal of SCEP is to support the secure issuance of certificates to network devices in a scalable manner, using existing technology whenever possible. The protocol supports the following operations: o CA and RA public key distribution o Certificate enrollment o Certificate query Nourse & Vilhuber Expires October 3, 2009 [Page 5] Internet-Draft SCEP April 2009 o CRL query SCEP makes extensive use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986]. 2.1. SCEP Entities The entity types defined in SCEP are o the requester (Section 2.1.1) (e.g., IPSEC clients) o the certification authority (Section 2.1.2) (CA) o the Registration Authority (Section 2.1.3) (RA) A requester is sometimes called a "SCEP client" in this document. 2.1.1. Requester A requester is an entity whose name is defined in a certificate subject field and optionally, in subjectAltName, a X.509 v3 certificate extension. Certificate requests for certificates whose purpose is a specific solution are encouraged to conform to the solution's profile, e.g. [RFC4945] section 5 for IKE/IPsec certificates. 2.1.1.1. Requester Initialization The requester initialization includes the key pair generation and the configuring of the required information to communicate with the certification authority. A requester MUST generate, and provide storage for, asymmetric key pairs. If the requester does not have enough permanent memory to save its certificate, then it should be able to query its own certificate from the CA or an LDAP server, once the certificate has been issued (see Section 3.2.3). 2.1.1.1.1. RSA Key Pairs Before a requester can start a PKI transaction, it MUST have at least one RSA key pair. Key pairs may be intended for particular purposes, such as encryption only or signing only. The usage of any associated certificate can be restricted by adding key usage and extended key usage attributes to the PKCS#10 [RFC2986]. If key usage is not present, the public key is assumed to be a general purpose key that may be used for all Nourse & Vilhuber Expires October 3, 2009 [Page 6] Internet-Draft SCEP April 2009 purposes. 2.1.1.1.2. non-RSA Keys SCEP does not support non-RSA keys. Though the protocol (being based on PKCS#7 [RFC2315]) does not preclude them, RSA is the only algorithm supported by current implementations. 2.1.1.1.3. Required Information A requester MUST have the following information configured before starting any PKI operations: 1. the certification authority IP address or fully qualified domain name, 2. the certification authority HTTP CGI script path, 3. the HTTP proxy information if there is no direct Internet connection to the server, 4. If CRLs are being published by the CA to an LDAP directory server, and there is a CRL Distribution Point containing only an X.500 directory name, then the client will need to know the LDAP server fully qualified domain name or IP address. CRL Distribution Points are discussed in more detail in [RFC5280]. 2.1.1.2. Trusted CA Store To support interoperability between IPSEC peers whose certificates are issued by different CAs, SCEP allows the users to configure multiple trusted certificates. Trusted certificates are configured as such in the client, based on some out-of-band means such as a "fingerprint". These trusted certificates are used to verify certificate chains that end in those certificates. 2.1.2. Certification Authority A certification authority (CA) is an entity whose name appears in the issuer field of a certificate. Before any PKI operations can occur, the CA generates its own public key pair and creates a self-signed CA certificate, or causes another CA to issue a certificate to it. CA key-rollover and certificate expiry is address in Appendix E. Nourse & Vilhuber Expires October 3, 2009 [Page 7] Internet-Draft SCEP April 2009 2.1.2.1. CA Certificate Fingerprint If a CA certificate is self-signed and not pre-provisioned on the client, a CA Certificate fingerprint will be used to authenticate the received CA Certificate. The fingerprint is created by calculating a SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate. Before any requester can start its enrollment, this CA certificate has to be configured at the entity side securely. 2.1.2.2. Certification Authority Policies A certification authority may enforce any arbitrary policies, including name policies, and apply them to the request, possibly causing the request to be rejected. The requester MUST NOT assume any of the fields, except for the public key, will be the same in the resulting certificate as in the request. 2.1.2.3. CRL's and CDP's The certification authority MUST either include a cRLDistributionPoint extension in every certificate it issues or answer CRL queries itself, in which case it MUST be online all the time. The certification authority SHOULD also either answer certificate queries or make certificates available via LDAP. 2.1.2.4. Name Uniqueness A CA MAY enforce the property that there be only one key pair for a given subject name and key usage combination at any given time. This property is called the certificate name uniqueness property. 2.1.2.5. Retransmission versus new request It is desirable that the CA enforce certificate-name uniqueness, but it is not mandatory. A CA that does not enforce uniqueness must provide some other mechanism to prevent the re-transmission of an enrollment request by a SCEP client from creating a second certificate. Nor can the second request merely be rejected. If a client times out from polling for a pending request it can resynchronize by reissuing the original request with the original subject name, key, and transaction ID. This should return the status of the original transaction, including the certificate, if it was granted. It should not create a new transaction unless the original certificate has been revoked, or the transaction arrives more than halfway through the validity period of the original certificate. Nourse & Vilhuber Expires October 3, 2009 [Page 8] Internet-Draft SCEP April 2009 An enrollment request that occurs more than halfway through the validity period of an existing certificate for the same subject name and key usage MAY be interpreted as a re-enrollment or renewal request and be accepted. A new certificate with new validity dates may be issued, even though the old one is still valid, if the CA policy permits, as described in Section 2.1.2.6.3. See also Appendix E. 2.1.2.6. Requester authentication As with every protocol that uses public-key cryptography, the association between the public keys used in the protocol and the identities with which they are associated must be authenticated in a cryptographically secure manner. This requirement is needed to prevent a "man-in-the-middle" attack, in which an adversary can manipulate the data as it travels between the protocol participants and subvert the security of the protocol. PKCS#10 [RFC2986] specifies the use of a PKCS#9 [RFC2985] challengePassword attribute to be sent as part of the enrollment request. SCEP uses this challengePassword to satisfy the above requirements for security. The PKCS#7 [RFC2315] envelope protects the privacy of the challenge password. 2.1.2.6.1. Manual enrollment authentication In the manual mode, the requester is required to wait until its identity can be verified by the CA operator using any reliable out- of-band method. To prevent a "man-in-the-middle" attack, a SHA-1, SHA-256, SHA-512, or MD5 'fingerprint' generated on the PKCS#10 [RFC2986] (before PKCS#7 [RFC2315] enveloping and signing) SHOULD be compared out-of-band between the CA operator and the requester. SCEP clients and CAs (or RAs, if appropriate) MUST display this fingerprint to the operator to enable this verification if manual mode is used. Failing to provide this information leaves the protocol vulnerable to attack by sophisticated adversaries. In this case the challenge password is only used to authenticate a request for the certificate's revocation. 2.1.2.6.2. Automated enrollment authentication When utilizing a pre-shared secret scheme, the server MAY distribute a shared secret to the requester, which will uniquely associate the enrollment request with the requester. The distribution of the secret must be private: only the end entity should know this secret. The actual binding mechanism between the requester and the secret is subject to the server policy and implementation. Nourse & Vilhuber Expires October 3, 2009 [Page 9] Internet-Draft SCEP April 2009 When using the pre-shared secret scheme, the requester MUST enter the pre-distributed secret as the challengePassword. The pre-shared secret MAY also be used to authenticate a request for the certificate's revocation. 2.1.2.6.3. Existing CA-Issued or Self-Signed Certificates In this protocol, the communication between the requester and the certification authority is secured by using PKCS#7 [RFC2315] as the messaging protocol (see Section 3). PKCS#7 [RFC2315], however, is a data format which assumes the communicating entities already possess the peer's certificates and requires that both parties use the subject names and issuer assigned certificate serial numbers to identify the certificate in order to verify the signature and decrypt the message. o If the requesting system already has a certificate issued by the CA, and the CA supports RENEWAL (see Appendix D), that certificate SHOULD be presented as credentials for the renewal of that certificate if the CA supports the "Renewal" capability and the CA policy permits the certificate to be renewed. o If the requesting system has no certificate issued by the CA, but has credentials from a different CA, and the CA supports RENEWAL (see Appendix D), that certificate MAY be presented as credentials instead of a self-signed certificate. Policy settings on the CA will determine if the request can be accepted or not. This is useful when enrolling with a new administrative domain, using a certificate from the old domain as credentials. o If the requester does not have an appropriate existing certificate, then a self-signed certificate MUST be used instead. The self-signed certificate MUST use the same subject name as in the PKCS#10 request. During the certificate enrollment, the requester MUST use the appropriate certificate to sign the PKCS#7 [RFC2315] (see Section 3). When the certification authority creates the PKCS#7 [RFC2315] envelope on the issued certificate, it SHOULD use the public key, issuer name, and serial number conveyed in the above included certificate. This will inform the end entity of which private key should be used to open the envelope. Note that when a client enrolls for separate encryption and signature certificates, it may use the signature certificate to sign both requests, and then expect its signature key to be used to encrypt Nourse & Vilhuber Expires October 3, 2009 [Page 10] Internet-Draft SCEP April 2009 both responses. In any case, the RecipientInfo on the envelope MUST reflect the key used to encrypt the request. 2.1.3. Registration Authority In an environment where a Registration Authority (RA) is present, a requester performs enrollment through the RA. In order to securely communicate with an RA using PKCS#7 [RFC2315], the client MUST use the RA's keys instead of the CA's keys. The RA certificate(s) (in addition to the CA certificate) will be returned in the GetCaCert Response (see Section 5.2.1.1.2) automatically. Clients MUST verify the authorization of the RA certificates. The authorization mechanism is specified by the CA administrator and is out of scope for this document. In the following, the CA and RA are specified as one entity in the context of PKI operation definitions. 2.2. SCEP Functionality In this section, we give a high level overview of the functionality of SCEP. 2.2.1. CA/RA Certificate Distribution If the CA and/or RA certificates have not previously been acquired by the requester in some other means, the requester MUST retrieve the CA/RA certificates before any PKI operation (Section 3) can be started. Since no public key has yet been exchanged between the requester and the CA/RA, the messages cannot be secured using PKCS#7 [RFC2315], and the data is instead transferred in the clear. If an RA is in use, a certificates-only PKCS#7 [RFC2315] SignedData with a certificate chain consisting of both RA and CA certificates is returned. Otherwise the CA certificate itself is returned. The transport protocol (Section 5) MUST indicate which one is returned. After the requester gets the CA certificate, it MUST authenticate the CA certificate by comparing the CA certificate fingerprint (see Section 2.1.2.1) with the CA/RA operator out-of-band. Since the RA certificates (if any) are signed by the CA, there is no need to authenticate the RA certificates. Nourse & Vilhuber Expires October 3, 2009 [Page 11] Internet-Draft SCEP April 2009 Because a long time can pass between queries from a requester to a CA/RA and because RA certificates can change at any time, it is recommended that a requester not store RA certificates. Instead, the requester SHOULD retrieve the CA/RA certificates before each operation. 2.2.2. Certificate Enrollment A requester starts an enrollment (Section 3.2.1) transaction by creating a certificate request using PKCS#10 [RFC2986] and sends it to the CA/RA enveloped using the PKCS#7 (Section 3). It is up to local CA policy (and CA implementation) as to whether a certificate is granted automatically, or whether it is manually granted by the administrator. The challengePassword MAY be used to automatically authenticate the request. If the CA/RA returns a CertRep (Section 3.2.2) message with status set to PENDING, the requester enters into polling mode by periodically sending a GetCertInitial (Section 3.2.3) PKI message to the CA/RA, until the CA/RA operator completes the manual authentication (approving or denying the request). In general, the requester will send a single PKCSReq (Section 3.2.1) message, followed by 0 or more GetCertInitial (Section 3.2.3) messages, if polling mode is entered. In general, the CA/RA will send 0 or more CertRep (Section 3.2.2) messages with status set to PENDING, followed by a single CertRep (Section 3.2.2) with status set to either SUCCESS or FAILURE. 2.2.2.1. State Transitions in Certificate Enrollment The requester state transitions during enrollment operation are indicated in Figure 1. Nourse & Vilhuber Expires October 3, 2009 [Page 12] Internet-Draft SCEP April 2009 GetCertInitial +----<---+ | | CertRep(PENDING), | | GetCertInitial send-timeout, | | new-poll timer | | [CERT-NONEXISTANT] -----+---> [CERT-REQ-PENDING] [CERT-ISSUED] ^ PKCSReq | | ^ | | | | | | +---------------+ | | CertRep(SUCCESS) +--------------------------+ CertRep(FAILURE), PKCSReq send-timeout, max-time/max-polls exceeded Figure 1: State Transition Diagram Certificate enrollment starts at the state CERT-NONEXISTANT. Sending a PKCSReq message changes the state to CERT-REQ-PENDING. If there is no response, or sending is not possible, the state reverts back to CERT-NONEXISTANT. Receiving a CertRep message with pkiStatus set to SUCCESS changes the state to CERT-ISSUED. Receiving a CertRep message with pkiStatus set to FAILURE changes the state to CERT-NONEXISTANT. If the server sends back a CertRep message with pkiStatus set to PENDING, the requester will keep polling by sending a GetCertInitial message to the server, until either a CertRep message with status set to SUCCESS is received, or the maximum number of polls has been exceeded. If the maximum number of polls has been exceeded or a CertRep message with pkiStatus set to FAILURE is received while in the CERT-REQ- PENDING state, the end entity will transition to the CERT-NONEXISTANT state, and the SCEP client can eventually initiate another enrollment request. It is important to note that, as long as the requester does not change its subject name or keys, the same transaction ID will be used in the "new" transaction. This is important because based on this transaction ID, the certification authority can recognize this as an existing transaction instead of a new one. Nourse & Vilhuber Expires October 3, 2009 [Page 13] Internet-Draft SCEP April 2009 A successful transaction in automatic mode: REQUESTER CA SERVER PKCSReq: PKI cert. enrollment msg --------------------------------> CertRep: pkiStatus = SUCCESS certificate attached <------------------------------ Receive issued certificate. Figure 2: Automatic mode transaction A successful transaction in manual mode: REQUESTER CA SERVER PKCSReq: PKI cert. enrollment msg --------------------------------> CertRep: pkiStatus = PENDING <------------------------------ GetCertInitial: polling msg --------------------------------> CertRep: pkiStatus = PENDING <------------------------------ ................ ............... GetCertInitial: polling msg --------------------------------> CertRep: pkiStatus = SUCCESS certificate attached <------------------------------ Receive issued certificate. Figure 3: Manual mode transaction 2.2.3. Certificate Access There are two methods to query certificates. The first method is to use LDAP as a query protocol. Using LDAP to query assumes the client understands the LDAP scheme supported by the CA. The SCEP client assumes that the subject DN in the certificate is used as the URL to query the certificate. The standard attributes (userCertificate and caCertificate) are used as filter. For the environment where LDAP is not available, a certificate query message is defined to retrieve the certificates from the CA. To query a certificate from the certification authority, a requester sends a request consisting of the certificate's issuer name and serial number. This assumes that the requester has saved the issuer name and the serial number of the issued certificate from the previous enrollment transaction. The transaction to query a certificate consists of one GetCert (Section 3.2.4) message and one CertRep (Section 3.2.2) message, as shown in Figure 4. Nourse & Vilhuber Expires October 3, 2009 [Page 14] Internet-Draft SCEP April 2009 REQUESTER CA SERVER GetCert: PKI certificate query msg -------------------------------> CertRep: pkiStatus = SUCCESS certificate attached <----------------------------- Receive the certificate. Figure 4: GetCert Transaction 2.2.4. CRL Access The CA/RA will not "push" the CRL to the end entities. The query of the CRL can only be initialized by the requester. There are two methods to retrieve a CRL: 1. If the CA supports CRL Distribution Points [RFC5280] (section 4.2.1.13), then the CRL MUST be retrieved via the mechanism specified in the CDP. 2. If the CA does not support CDP's, a CRL query is composed by creating a message consisting of the subject name and serial number of the certification authority's certificate. This method is deprecated because * it does not scale well * requires the CA to be a high-availability service * does not provide sufficient information to determine the CRL scope (see [RFC5280] Section 5) other than "all certificates by this CA". The message is sent to the CA in the same way as the other SCEP requests: The transaction to retrieve a CRL consists of one GetCRL PKI message and one CertRep PKI message, which contains only the CRL (no certificates), as shown in Figure 5. REQUESTER CA SERVER GetCRL: PKI CRL query msg ----------------------------------> CertRep: CRL attached <-------------------------------- Figure 5: GetCRL Transaction Nourse & Vilhuber Expires October 3, 2009 [Page 15] Internet-Draft SCEP April 2009 2.2.5. Certificate Revocation SCEP currently only allows revocation as an out-of-band process. In order to revoke a certificate, the requester must contact the CA server operator, who MAY wish to verify the challenge password (which has been sent to the server as an attribute of the PKCS#10 [RFC2986] certificate request). If the challenge password matches, the certificate can be revoked. 2.3. PKI Operation Transactional Behavior As described before, a PKI operation is a transaction consisting of the messages exchanged between a requester and the CA/RA. This section will specify the transaction behavior on both the requester and the certification authority server. Because the protocol is basically a two way communication protocol without a confirmation message from the initiating side, state and state resynchronization rules have to be defined, in case any error happens at either side. Before the state transition can be defined, the notion of transaction identifier has to be defined first. 2.3.1. Transaction Identifier A transaction identifier is a string generated by the entity when starting a transaction. Since all the PKI operations defined in this protocol are initiated by the requester, it is the responsibility of the requester to generate a unique string as the transaction identifier. All the PKI messages exchanged for a given PKI transaction must carry the same transaction identifier. The transaction identifier is generated as a SHA-1, SHA-256, SHA-512 or MD5 hash on the public key value for which the enrollment request is made. This allows the SCEP client to reuse the same transaction identifier if it is reissuing a request for the same certificate (i.e. a certificate with the same subject, issuer, and key). The SCEP protocol requires that transaction identifiers be unique, so that queries can be matched up with transactions. For this reason, in those cases in which separate signing and encryption certificates are issued to the same requester, the keys must be different. 2.3.2. Transaction Behavior of Certificate/CRL Access There is no state maintained during certificate access and CRL access transaction. When using the certificate query and CRL query messages defined in this protocol, the transaction identifier is still required so that the requester can match the response message with the outstanding request message. When using LDAP to query the Nourse & Vilhuber Expires October 3, 2009 [Page 16] Internet-Draft SCEP April 2009 certificate and the CRL, the behavior is specified by the LDAP protocol. 2.4. Security The security goals of SCEP are that no adversary can: o subvert the public key/identity binding from that intended, o discover the identity information in the enrollment requests and issued certificates, o cause the revocation of certificates with any non-negligible probability. Here an adversary is any entity other than the requester and the CA (and optionally the RA) participating in the protocol that is computationally limited, but that can manipulate data during transmission (that is, a man-in-the-middle). The precise meaning of 'computationally limited' depends on the implementer's choice of cryptographic hash functions and ciphers. The required algorithms are RSA, DES and MD5. Depending on the CA capabilities (see Appendix D), Triple-DES MAY be used instead of DES, and SHA-1, SHA- 256, or SHA-512 MAY be used instead of MD5. The first and second goals are met through the use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures using authenticated public keys. The CA's public key is authenticated via the checking of the CA fingerprint, as specified in Section 2.1.2, and the SCEP client's public key is authenticated through the manual authentication or pre-shared secret authentication, as specified in Section 2.1.2.6. The third goal is met through the use of a challenge password for revocation, which is chosen by the SCEP client and communicated to the CA protected by the PKCS#7 [RFC2315] encryptedData, as specified in Section 2.2.5. The motivation of the first security goal is straightforward. The motivation for the second security goal is to protect the identity information in the enrollment requests and certificates. For example, two IPSEC hosts behind a firewall may need to exchange certificates, and may need to enroll certificates with a CA that is outside of a firewall. Most networks with firewalls seek to prevent IP addresses and DNS information from the trusted network leaving that network. The second goal enables the hosts in this example to enroll with a CA outside the firewall without revealing this information. The motivation for the third security goal is to protect the SCEP clients Nourse & Vilhuber Expires October 3, 2009 [Page 17] Internet-Draft SCEP April 2009 from denial of service attacks. 3. SCEP Secure Message Objects PKCS#7 [RFC2315] is a general enveloping mechanism that enables both signed and encrypted transmission of arbitrary data. All messages MUST be valid PKCS#7 [RFC2315] structures, unless otherwise noted. SCEP messages that require confidentiality use two layers of PKCS#7, as shown in Figure 6. By applying both enveloping and signing transformations, the SCEP message is protected both for the integrity of its end-to-end transaction information and the confidentiality of its information portion. The advantage of this technique over the conventional transaction message format is that the signed transaction type information and the status of the transaction can be determined prior to invoking security handling procedures specific to the information portion being processed. Some messages do not require enveloping, in which case the EnvelopedData in Figure 6 is omitted. ContentType = SignedData (called pkiMessage) SignerInfo Signature authenticatedAttributes transactionID messageType pkiStatus failInfo senderNonce recipientNonce etc ContentInfo type = EnvelopedData (called pkcsPKIEnvelope; optional) RecipientInfo ContentInfo type = Data messageData Figure 6: PKCS#7 Layering Description: o The outer PKCS#7 is a pkiMessage (Section 3.1). o The SignedData ContentInfo, if present (e.g. FAILURE and PENDING CertRep messages will lack any signed content), MUST be a Nourse & Vilhuber Expires October 3, 2009 [Page 18] Internet-Draft SCEP April 2009 pkcsPKIEnvelope (Section 3.1.2). When a particular SCEP message carries data, this data is carried in the messageData. Note: The remainder of this document will refer only to 'messageData', but it is understood to always be encapsulated in the pkcsPKIEnvelope (Section 3.1.2). The format of the data in the messageData is defined by the messageType attribute (see Section 3.1.1) of the SignedData. If there is no messageData to be transmitted, the entire pkcsPKIEnvelope MUST be omitted. 3.1. SCEP pkiMessage The basic building block of all secured SCEP messages is the SCEP pkiMessage. It consists of an PKCS#7 signed-data content type, as defined in PKCS#7 [RFC2315] Section 9. The following restrictions apply: o version MUST be 1 o the contentType in contentInfo MUST be data ({pkcs-7 1}) as defined in PKCS#7 [RFC2315] Section 8. o The signed content, if present (e.g. FAILURE and PENDING CertRep messages will lack any signed content), MUST be a pkcsPKIEnvelope (Section 3.1.2), and must match the messageType attribute. o The SignerInfo MUST contain a set of authenticatedAttributes (see PKCS#7 [RFC2315] Section 9.2 as well as Section 3.1.1 in this document). All messages MUST contain * an SCEP transactionID attribute * an SCEP messageType attribute * an SCEP senderNonce attribute * any attributes required by PKCS#7 [RFC2315] section 9.2 If the message is a response, it MUST also include * an SCEP pkiStatus attribute * an SCEP responderNonce attribute Nourse & Vilhuber Expires October 3, 2009 [Page 19] Internet-Draft SCEP April 2009 3.1.1. Signed Transaction Attributes The following transaction attributes are encoded as authenticated attributes, and are carried, as specified in PKCS#7 [RFC2315] Section 9.2, in the SignerInfo for this signedData. Please refer to Appendix B for the OID definitions. +----------------+-----------------+---------------------------+ | Attribute | Encoding | Comment | +----------------+-----------------+---------------------------+ | transactionID | PrintableString | Hash value as a string | | messageType | PrintableString | Decimal value as a string | | pkiStatus | PrintableString | Decimal value as a string | | failInfo | PrintableString | Decimal value as a string | | senderNonce | OctetString | | | recipientNonce | OctetString | | +----------------+-----------------+---------------------------+ Transaction Attributes The attributes are detailed in the following sections. 3.1.1.1. transactionID The transactionID is an attribute that uniquely identifies a transaction. This attribute MUST be included in all PKI messages. The transactionID SHOULD be the MD5 hash of the public key from the request, encoded as a PrintableString. The transactionID MUST be unique to a given public key, so that any new requests for certificates using the same key can be detected as duplicates by the server (see Section 8.4). For a non-enrollment message (for example GetCert and GetCRL), the transactionID SHOULD be a number unique to the client. 3.1.1.2. messageType The messageType attribute specifies the type of operation performed by the transaction. This attribute MUST be included in all PKI messages. Currently, the following message types are defined: o PKCSReq (19) -- PKCS#10 [RFC2986] certificate request o CertRep (3) -- Response to certificate or CRL request Nourse & Vilhuber Expires October 3, 2009 [Page 20] Internet-Draft SCEP April 2009 o GetCertInitial (20) -- Certificate polling in manual enrollment o GetCert (21) -- Retrieve a certificate o GetCRL (22) -- Retrieve a CRL 3.1.1.3. pkiStatus All response messages MUST include transaction status information, which is defined as pkiStatus attribute: o SUCCESS (0) -- request granted o FAILURE (2) -- request rejected. When pkiStatus is FAILURE, the failInfo attribute, as defined in Section 3.1.1.4, MUST also be present. o PENDING (3) -- request pending for manual approval 3.1.1.4. failInfo The failInfo attribute MUST contain one of the following failure reasons: o badAlg (0) -- Unrecognized or unsupported algorithm identifier o badMessageCheck (1) -- integrity check failed o badRequest (2) -- transaction not permitted or supported o badTime (3) -- The signingTime attribute from the PKCS#7 SignedAttributes was not sufficiently close to the system time (see Section 3.1.1.6). o badCertId (4) -- No certificate could be identified matching the provided criteria 3.1.1.5. senderNonce and responderNonce The attributes of senderNonce and recipientNonce are 16 byte random numbers generated for each transaction to prevent replay attacks. When a requester sends a PKI message to the server, a senderNonce MUST be included in the message. The responder SHOULD copy the senderNonce into the recipientNonce of the reply as a proof of liveliness. Nourse & Vilhuber Expires October 3, 2009 [Page 21] Internet-Draft SCEP April 2009 The requester SHOULD verify that the recipientNonce of the reply matches the senderNonce it sent in the request. 3.1.1.6. signingTime Attribute The signingTime Attribute is defined in [RFC2985] Section 5.3.3, and is carried as defined in a [RFC2315] authenticated attribute (Section 9.2). This attribute is optional. 3.1.2. SCEP pkcsPKIEnvelope The information portion of a SCEP message is carried inside an enveloped-data content type, as defined in PKCS#7 [RFC2315] Section 10, with the following restrictions: o version MUST be 0 o contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as defined in PKCS#7 [RFC2315] Section 8. o encryptedContent MUST be the SCEP message being transported (see Section 4), and must match the messageType signedAttribute in the pkiMessage. The message is encrypted using the public key of the recipient of the message, i.e. the RA or the CA public key (if sent from the requester), or the requester public key (if sent as a reply to the requester). 3.2. SCEP pkiMessage types All of the messages in this section are pkiMessages (Section 3.1), where the type of the message MUST be specified in the 'messageType' Signed Attribute. Each section defines a valid message type, the corresponding messageData formats, and mandatory signed attributes for that type. 3.2.1. PKCSReq The messageData for this type consists of a DER-encoded PKCS#10 Certification Request [RFC2986]. The certification request MAY contain any fields defined in PKCS#10 [RFC2986], and MUST contain at least the following items: o the subject Distinguished Name o the subject public key Nourse & Vilhuber Expires October 3, 2009 [Page 22] Internet-Draft SCEP April 2009 o a challengePassword attribute. The Challenge Password may be used to (out-of-band) authenticate the enrollment request itself, or in an out-of-band revocation request for the issued certificate. In addition to the authenticatedAttributes required for a valid PKCS#7 [RFC2315], this pkiMessage MUST include the following attributes: o a transactionID (Section 3.1.1.1) attribute o a messageType (Section 3.1.1.2) attribute set to PKCSReq o a senderNonce (Section 3.1.1.5) attribute The pkcsPKIEnvelope for this message type is encrypted using the public key of the recipient, i.e. the CA or RA public key. 3.2.2. CertRep The messageData for this type consists of a DER-encoded degenerate certificates-only Signed-data (Section 3.3). The exact contents required for certain CertRep replies depends on the type of request this message is a reply to and is detailed in Table 1 and in Section 4. In addition to the authenticatedAttributes required for a valid PKCS#7 [RFC2315], this pkiMessage MUST include the following attributes: o the transactionID (Section 3.1.1.1) attribute copied from the request we are responding to o a messageType (Section 3.1.1.2) attribute set to CertRep o a senderNonce (Section 3.1.1.5) attribute o a recipientNonce attribute (Section 3.1.1.5) copied from the senderNonce from the request we are responding to. o a pkiStatus (Section 3.1.1.3) set to the status of the reply. The pkcsPKIEnvelope of a CertRep (if present), MUST be encrypted with the same certificate used to sign the PKCSReq this message is a reply to, according to section 10 in PKCS#7 [RFC2315]. This means that if a self-signed certificate was used to send the request, this self- signed certificate will be reflected in the recipientInfo field of the envelopedData, in accordance with PKCS#7 [RFC2315] section 10. Nourse & Vilhuber Expires October 3, 2009 [Page 23] Internet-Draft SCEP April 2009 3.2.2.1. CertRep SUCCESS When the pkiStatus attribute is set to SUCCESS, the messageData for this message consists of a DER-encoded degenerate certificates-only Signed-data (Section 3.3). The contents of this degenerate certificatess-only Signed-Data depends on what the original request was, as outlined in Table 1. +----------------+--------------------------------------------------+ | Request-type | Reply-contents | +----------------+--------------------------------------------------+ | PKCSReq | the reply MUST contain at least the issued | | | certificate attached to the certificates field | | | of the Signed-Data. The reply MAY contain | | | additional certificates, but the issued | | | certificate MUST be the first in the list. The | | | reply MUST NOT contain any CRL's. All returned | | | certificates MUST conform to [RFC5280]. | | GetCertInitial | same as PKCSReq | | GetCert | the reply MUST contain at least the requested | | | certificate attached to the certificates field | | | of the Signed-Data. The reply MAY contain | | | additional certificates, but the requested | | | certificate MUST be the first in the list. The | | | reply MUST NOT contain any CRL's. All returned | | | certificates MUST conform to [RFC5280]. | | GetCRL | the reply MUST contain the CRL attached to the | | | crls field of the Signed-Data. The reply MUST | | | NOT contain any certificates. The CRL MUST be a | | | valid CRL according to [RFC5280]. | +----------------+--------------------------------------------------+ Table 1: CertRep Types 3.2.2.2. CertRep FAILURE When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a failInfo (Section 3.1.1.4) attribute set to the appropriate error condition decribing the failure. The pkcsPKIEnvelope (Section 3.1.2) MUST be omitted. 3.2.2.3. CertRep PENDING When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (Section 3.1.2) MUST be omitted. Nourse & Vilhuber Expires October 3, 2009 [Page 24] Internet-Draft SCEP April 2009 3.2.3. GetCertInitial The messageData for this type consists of a DER-encoded IssuerAndSubject (Section 3.2.3.1). The issuer is set to the issuerName from the certification authority from which we are issued certificates. The Subject is set to the SubjectName we used when requesting the certificate. In addition to the authenticatedAttributes required for a valid PKCS#7 [RFC2315], this pkiMessage MUST include the following attributes: o the same transactionID (Section 3.1.1.1) attribute from original PKCSReq message o a messageType (Section 3.1.1.2) attribute set to GetCertInitial o a senderNonce (Section 3.1.1.5) attribute 3.2.3.1. IssuerAndSubject Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section 6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7). The ASN.1 definition of the issuerAndSubject type is as follows: issuerAndSubject ::= SEQUENCE { issuer Name, subject Name } Figure 7: IssuerAndSubject ASN.1 3.2.4. GetCert The messageData for this type consists of a DER-encoded IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7 containing the "distinguished name of the certificate issuer and an issuer- specific certificate serial number" which uniquely identifies the certificate we are requesting. In addition to the authenticatedAttributes required for a valid PKCS#7 [RFC2315], this pkiMessage MUST include the following attributes: o a transactionID (Section 3.1.1.1) attribute o a messageType (Section 3.1.1.2) attribute set to PKCSReq Nourse & Vilhuber Expires October 3, 2009 [Page 25] Internet-Draft SCEP April 2009 o a senderNonce (Section 3.1.1.5) attribute If this is a query for its own certificate (assume the requester lost the issued certificate, or does not have enough non-volatile memory to save the certificate), then a self-signed certificate has to be included in the signed envelope. 3.2.5. GetCRL The messageData for this type consists of a DER-encoded IssuerAndSerial as defined in PKCS#7 [RFC2315] Section 6.7. The issuer is set to the SubjectName of the certification authority which issued the certificate revocation list we are requesting. The serial number is the CA certificate's serial number. In addition to the authenticatedAttributes required for a valid PKCS#7 [RFC2315], this pkiMessage MUST include the following attributes: o a transactionID (Section 3.1.1.1) attribute o a messageType (Section 3.1.1.2) attribute set to PKCSReq o a senderNonce (Section 3.1.1.5) attribute 3.3. Degenerate certificates-only PKCS#7 Signed-data [RFC2315] section 9 mentions a degenerate case of the PKCS#7 Signed- data content type, in which there are no signers. The use of such a degenerate case is to disseminate certificates and certificate- revocation lists. SCEP makes use of this degenerate case, calling it a "degenerate certificates-only PKCS#7 Signed-data". Though not required by PKCS#7 [RFC2315], for SCEP the ContentInfo of a degenerate certificates-only Signed-Data MUST be empty. When carrying certificates, the certificates are attached to the 'certificates' field of the Signed-Data. When carrying a CRL, the CRL will be attached to the 'crls' field of the Signed-Data. 4. SCEP Transactions This section describes the SCEP Transactions, without explaining the transport. The transport of each message is discussed in Section 5. Some of the transaction-requests have no data to send, i.e. the only data is the message-type itself (e.g. a GetCaCert message has no additional data). The use of such messages will become clearer in Section 5. Nourse & Vilhuber Expires October 3, 2009 [Page 26] Internet-Draft SCEP April 2009 In this section, each SCEP transaction is specified in terms of the complete messages exchanged during the transaction. The order of the transactions in this section is mirrored in Section 5.2 for better organization and readability. 4.1. Get CA Certificate To get the CA certificate(s), the requester sends a GetCACert message to the server. There is no request data associated with this message (see Section 5.2.1). 4.1.1. Get CA Certificate Response Message Format The response depends on whether the responding server has RA certificates or only a single CA certificate. The server MUST indicate which response it is sending via the transport protocol used (see Section 5.2.1). All returned certificates MUST conform to [RFC5280]. Once the CA certificate is received by the requester (regardless of the presence of RA certificates), a fingerprint is generated using the SHA1, SHA256, SHA512 or MD5 hash algorithm on the whole CA certificate. If the requester does not have a certificate path to a trusted CA certificate, this fingerprint may be used to verify the certificate, by some positive out-of-band means, such as a phone call or pre-provisioning. 4.1.1.1. CA Certificate Response Message Format If the server is a certification authority and does not have any RA Certificates, the response consists of a single DER-encoded X.509 CA certificate. 4.1.1.2. CA/RA Certificate Response Message Format If the server has RA Certificates, the response consists of a DER- encoded degenerate certificates-only Signed-data (Section 3.3) containing the CA certificate and RA certificates. 4.2. Certificate Enrollment A PKCSReq (Section 3.2.1) message is used to perform a certificate enrollment transaction. The reply MUST be a CertRep (Section 3.2.2) message sent back from the server, indicating SUCCESS, FAILURE, or PENDING. Nourse & Vilhuber Expires October 3, 2009 [Page 27] Internet-Draft SCEP April 2009 Precondition: Both the requester and the certification authority have completed their initialization process. The requester has already been configured with the CA/RA certificate. Postcondition: Either the certificate is received by the requester, or the end entity is notified to do the manual authentication, or the request is rejected. 4.2.1. Certificate Enrollment Response Message If the request is granted, a CertRep (Section 3.2.2) message with pkiStatus set to SUCCESS is returned. The reply MUST also contain the certificate (and MAY contain any other certificates needed by the requester). The issued certificate MUST be the first in the list. If the request is rejected, a CertRep (Section 3.2.2) message with pkiStatus set to FAILURE is returned. The reply MUST also contain a failInfo attribute. If the the CA is configured to manually authenticate the requester, a CertRep (Section 3.2.2) message with pkiStatus set to PENDING is returned.. 4.3. Poll for Requester Initial Certificate Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING, a requester will enter the polling state by periodically sending GetCertInitial (Section 3.2.3) to the server, until either the request is granted and the certificate is sent back, or the request is rejected, or the configured time limit for polling (or maximum number of polls) is exceeded. Since GetCertInitial is part of the enrollment, the messages exchanged during the polling period should carry the same transactionID attribute as the previous PKCSReq. A server receiving a GetCertInitial for which it does not have a matching PKCSReq MUST ignore this request. Since at this time the certificate has not been issued, the requester can only use its own subject name (which was contained in the original PKCS#10 sent via PKCSReq) to identify the polled certificate request. Since there can be multiple outstanding requests from one requester (for example, if different keys and different key-usages were used to request multiple certificates), the transaction ID must also be included, to disambiguate between multiple requests. PreCondition: Either the requester has received a CertRep with pkiStatus set to PENDING, or waiting for a previous PKCSReq has timed Nourse & Vilhuber Expires October 3, 2009 [Page 28] Internet-Draft SCEP April 2009 out. PostCondition: The requester has either received a valid response, which could be either a valid certificate (pkiStatus == SUCCESS), or a FAILURE message, or the polling period times out. 4.3.1. Polling Response Message Format The response messages for GetCertInitial are the same as in Section 4.2.1. 4.4. Certificate Access The certificate query message is an option when the LDAP server is not available to provide the certificate query. A requester should be able to query an issued certificate from the certification authority, as long as the issuer name and the issuer assigned certificate serial number is known to the requesting end entity. This transaction is not intended to provide the service as a certificate directory service. A more complicated query mechanism would have to be defined in order to allow a requester to query a certificate using various different fields. This transaction consists of one GetCert (Section 3.2.4) message sent to the server by a requester, and one CertRep (Section 3.2.2) message sent back from the server. PreCondition: The queried certificate have been issued by the certification authority and the issuer assigned serial number is known. PostCondition: Either the certificate is sent back or the request is rejected. 4.4.1. Certificate Access Response Message Format In this case, the CertRep from the server is same as in Section 4.2.1, except that the server will only either grant the request (SUCCESS) or reject the request (FAILURE). Also, the recipientInfo should use the CA issuer name and CA assigned serial number to identify the requester's key pair since at this time, the requester has received its own certificate. 4.5. CRL Access The CRL query message is an option when the LDAP server is not available to provide the CRL query. In the PKI protocol proposed Nourse & Vilhuber Expires October 3, 2009 [Page 29] Internet-Draft SCEP April 2009 here, only the requester can initiate the transaction to download CRL. A requester sends GetCRL (Section 3.2.5) request to the server and the server sends back CertRep (Section 3.2.2) whose information portion is a degenerate certificates-only Signed-data (Section 3.3) which contains only the most recent CRL. The size of CRL included in the CertRep should be determined by the implementation. When a CRLDistributionPoint is used, the GetCRL exchange should not be used. Instead, the CRLDistributionPoint, as set in the certificate, should be queried (see [RFC5280] section 4.2.1.14). PreCondition: The certification authority certificate has been downloaded to the end entity. PostCondition: CRL sent back to the requester. 4.5.1. CRL Access Response Message Format The CRL is sent back to the requester through CertRep message. The information portion of this message is a degenerate certificates-only Signed-data (Section 3.3) which contains only CRL attached to the crls field of the Signed-Data. 4.6. Get Next Certification Authority Certificate When a CA certificate is about to expire, clients need to retrieve the CA's next CA certificate (i.e. the Rollover Certificate). This is done via the GetNextCaCert message. There is no request data associated with this message (see Section 5.2.6). 4.6.1. Get Next CA Response Message Format The response consists of a SignedData PKCS#7 [RFC2315], signed by the current CA (or RA) signing key. Clients MUST validate the signature on the the SignedData PKCS#7 [RFC2315] before accepting any of its contents. The content of the SignedData PKCS#7 [RFC2315] is a degenerate certificates-only Signed-data (Section 3.3) message containing the new CA certificate and any new RA certificates, as defined in Section 5.2.1.1.2, to be used when the current CA certificate expires. If the CA (or RA) does not have the Rollover certificate(s) it MUST reject the request. It SHOULD also remove the GetNextCaCert setting Nourse & Vilhuber Expires October 3, 2009 [Page 30] Internet-Draft SCEP April 2009 from the capabilities until it does have rollover certificates. If there are any RA certificates in this response, clients MUST check that these RA certificates are signed by the CA, and MUST check authorization of these RA certificates (see Section 2.1.3). 5. Transport Protocol In the SCEP protocol, HTTP is used as the transport protocol for the PKI messages. 5.1. HTTP "GET" Message Format SCEP uses the HTTP "GET" messages to request information from the CA. The following is the syntax definition of a HTTP GET message sent from a requester to a certification authority server: "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE General GET Syntax where: o CGI-PATH defines the actual CGI path to invoke the CGI program that parses the request. o CGI-PROG is set to be the string "pkiclient.exe". This is intended to be the program that the CA will use to handle the SCEP transactions, though the CA may ignore CGI-PROG and use only the CGI-PATH. o OPERATION depends on the SCEP transaction and is defined in the following sections. o MESSAGE depends on the SCEP transaction and is defined in the following sections. If the CA supports it, requests may also be done via an HTTP POST. This is described in Appendix F. 5.1.1. Response Message Format For each GET operation, the CA/RA server MUST return a Content-Type and appropriate response data, if any. Nourse & Vilhuber Expires October 3, 2009 [Page 31] Internet-Draft SCEP April 2009 5.2. SCEP HTTP Messages 5.2.1. GetCACert OPERATION MUST be set to "GetCACert". MESSAGE MAY be ommitted, or it MAY be a string that represents the certification authority issuer identifier, if such has been set by the CA Administrator. 5.2.1.1. GetCACert Response The response for GetCACert is different between the case where the CA directly communicated with the requester during the enrollment, and the case where a RA exists and the requester communicates with the RA during the enrollment. 5.2.1.1.1. CA Certificate Only Response The response will have a Content-Type of "application/ x-x509-ca-cert". The body of this response consists of a DER-encoded X.509 CA certificate, as defined in Section 4.1.1.1. "Content-Type:application/x-x509-ca-cert\n\n" CA Certificate Response 5.2.1.1.2. CA and RA Certificates Response The response will have a Content-Type of "application/ x-x509-ca-ra-cert". The body of this response consists of a DER-encoded degenerate certificates-only Signed-data (Section 3.3) containing both CA and RA certificates, as defined in Section 4.1.1.2. "Content-Type:application/x-x509-ca-ra-cert\n\n" RA Certificate Response 5.2.2. PKCSReq OPERATION MUST be set to "PKIOperation". MESSAGE consists of a base64-encoded DER-encoded PKCSReq SCEP message. An example PKIOperation request might look as follows: Nourse & Vilhuber Expires October 3, 2009 [Page 32] Internet-Draft SCEP April 2009 GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0 PKCSReq Example 5.2.2.1. PKCSReq Response The response will have a Content-Type of "application/x-pki-message". The body of this response consists of a DER-encoded CertRep SCEP message defined in Section 4.2.1. The following is an example of the response: "Content-Type:application/x-pki-message\n\n" CertRep Example 5.2.3. GetCertInitial OPERATION MUST be set to "PKIOperation". MESSAGE consists of a base64-encoded DER-encoded GetCertInitial SCEP message. 5.2.3.1. GetCertInitial Response The body of this response consists of a DER-encoded CertRep SCEP message defined in Section 4.3.1. 5.2.4. GetCert OPERATION MUST be set to "PKIOperation". MESSAGE consists of a base64-encoded DER-encoded GetCert SCEP message. 5.2.4.1. GetCert Response The body of this response consists of a DER-encoded CertRep SCEP message defined in Section 4.4.1. 5.2.5. GetCRL OPERATION MUST be set to "PKIOperation". MESSAGE consists of a base64-encoded DER-encoded GetCRL SCEP message. Nourse & Vilhuber Expires October 3, 2009 [Page 33] Internet-Draft SCEP April 2009 5.2.5.1. GetCRL Response The body of this response consists of a DER-encoded CertRep SCEP message defined in Section 4.5.1. 5.2.6. GetNextCaCert OPERATION MUST be set to "GetNextCaCert". MESSAGE MAY be ommitted, or it MAY be a string that represents the certification authority issuer identifier, if such has been set by the CA Administrator. 5.2.6.1. GetNextCACert Response The response will have a Content-Type of "application/ x-x509-next-ca-cert". The body of this response consists of a SignedData PKCS#7 [RFC2315], as defined in Section 4.6.1. "Content-Type:application/x-x509-ca-ra-cert\n\n" > GetNextCaCert Example 6. Contributors/Acknowledgements The editor would like to thank all the previous authors: Cheryl Madson, Xiaoyi Liu, David McGrew, etc for their work on the draft over the years. The authors would like to thank Peter William of ValiCert, Inc. (formerly of VeriSign, Inc) and Alex Deacon of VeriSign, Inc. and Christopher Welles of IRE, Inc. for their contributions to this protocol and to this document. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations Nourse & Vilhuber Expires October 3, 2009 [Page 34] Internet-Draft SCEP April 2009 8.1. General Security Common key-management considerations such as keeping private keys truly private and using adequate lengths for symmetric and asymmetric keys must be followed in order to maintain the security of this protocol. This is especially true for CA keys, which, when compromised, compromise the security of all relying parties. 8.2. Use of the CA keypair A CA key pair is generally meant for (and is usually flagged as) "certificate signing" (exclusively), rather than 'data signing' or 'data encryption'. The SCEP protocol, however, uses the CA key pair to encrypt and sign PKCS#7 [RFC2315] transport messages, regardless of the key usage of the CA certificate. This is generally considered undesirable, as it widens the possibility of an implementation weakness, and provides o another place that the private key must be used (and hence is slightly more vulnerable to exposure), o another place where a side channel attack (say, timing or power analysis) might be used, o another place that the attacker might somehow insert his own text, and get it signed by the private key. While the CA key pair can be generated with the 'data encryption' and 'data signing' flags set, this is operationally not encouraged. It would make using the key as a PKCS#7 [RFC2315] transport key 'legal', but the discussion from the previous paragraph still applies. A solution is to use RA keys to secure the SCEP transport (i.e. message signing and encrypting), which allows the CA keys to be used only for their intended purpose of "certificate signing". An RA can be implemented in two ways: physically separate or implicit. In the implicit case, the CA simply creates an extra key pair. A physically separate RA allows the CA to be inside the secure network, not accessible to hackers at all. 8.3. ChallengePassword The challengePassword sent in the PKCS#10 enrollment request is signed and encrypted by way of being encapsulated in a pkiMessage. When saved by the CA, care should be taken to protect this password. Nourse & Vilhuber Expires October 3, 2009 [Page 35] Internet-Draft SCEP April 2009 If the challengePassword is used to automatically authenticate an enrollment request, it is recommended that some form of one-time password be used to minimize damage in the event the data is compromised. 8.4. transactionID A well-written CA/RA SHOULD NOT rely on the transactionID to be correct or as specified in this document. Requesters with buggy software might add additional undetected duplicate requests to the CA's queue (or worse). A well-written CA/RA should never assume the data from a requester is well-formed. On the other hand, a CA/RA MAY use the transactionID to reject previously handled requests with the same transactionID, reducing operational overhead. This has the side-effect, that ill-behaved clients will not receive a successful response to requests using the same transactionID. 8.5. Nonces and Replay In order to detect replay attacks, both sides need to maintain state information sufficient to detect a repeated, duplicate senderNonce. Since existing implementations do not copy the senderNonce from a CertRep into subsequent GetCertinitial requests, the server will never see its own nonce reflected back to it. The transactionID links together the GetCertInitial and PKCSReq, in any case. 8.6. Key Usage Issues When building a pkiMessage, clients MUST have a certificate to sign the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires it). Client can either use an existing certificate, or they MUST create a self-signed certificate (see Section 2.1.2.6.3). If this certificate has a key usage extension with it, then this key usage MUST be ignored by both the SCEP client and SCEP server for the duration of the transaction (the key will be used for signing during the creation of the PKCSReq message, and for encryption during the creation of the CertRep message). 8.7. GetCACaps Issues The GetCACaps response is not signed. This allows an attacker to use downgrade attacks (as well as "upgrade attacks") on the cryptographic capabilities of the CA. Nourse & Vilhuber Expires October 3, 2009 [Page 36] Internet-Draft SCEP April 2009 8.8. Unnecessary cryptography Some of the SCEP exchanges use signing and encryption operations that are not necessary. In particular the GetCert and GetCRL exchanges are encrypted and signed (in both directions), where simply signing the request would suffice (CRL's and Certificates, i.e. the respective responses, are already signed by the CA and can be verified by the recipient). This may affect performance and scalability of the CA which could be used as an attack vector on the CA (though not an anonymous one). The use of CDP's is recommended for CRL access, as well as other ways of retrieving certificates (LDAP, direct HTTP access, etc). 8.9. GetNextCaCert Versions of SCEP prior to 19 do not specifiy a correct GetNextCaCert response. Versions of SCEP prior to revision 3 do not support GetNextCACert. 9. Intellectual Property This protocol includes the optional use of Certificate Revocation List Distribution Point (CRLDP) technology, which is a patented technology of Entrust Technologies, Inc. (Method for Efficient Management of Certificate Revocation Lists and Update Information (U.S. Patent 5,699,431)). Please contact Entrust Technologies, Inc. (www.entrust.com) for more information on licensing CRLDP technology. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Nourse & Vilhuber Expires October 3, 2009 [Page 37] Internet-Draft SCEP April 2009 Request Syntax Specification Version 1.7", RFC 2986, November 2000. [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Appendix A. IPSEC Client Enrollment Certificate Request The following is the certificate enrollment request (PKCS#10 [RFC2986]) as created by Cisco VPN Client: -----END NEW CERTIFICATE REQUEST----- 0 30 439: SEQUENCE { 4 30 288: SEQUENCE { 8 02 1: INTEGER 0 11 30 57: SEQUENCE { 13 31 55: SET { 15 30 53: SEQUENCE { 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 22 13 46: PrintableString : 'For Xiaoyi, IPSEC attrs in alternate name extn' : } : } : } 70 30 158: SEQUENCE { 73 30 13: SEQUENCE { 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 86 05 0: NULL Nourse & Vilhuber Expires October 3, 2009 [Page 38] Internet-Draft SCEP April 2009 : } 88 03 140: BIT STRING 0 unused bits : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 : [ Another 11 bytes skipped ] : } 231 A0 63: [0] { 233 30 61: SEQUENCE { 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 14) 246 31 48: SET { 248 30 46: SEQUENCE { 250 30 44: SEQUENCE { 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 257 04 37: OCTET STRING 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 6E 2E 69 72 65 2E 63 6F 6D : } : } : } : } : } : } 296 30 13: SEQUENCE { 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 1 1 4) 309 05 0: NULL : } 311 03 129: BIT STRING 0 unused bits : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 : } Nourse & Vilhuber Expires October 3, 2009 [Page 39] Internet-Draft SCEP April 2009 Certificate Enrollment Request Appendix B. Private OID Definitions The OIDs used in SCEP are VeriSign self-maintained OIDs. +-------------------+-----------------------------------------------+ | Name | ASN.1 Definition | +-------------------+-----------------------------------------------+ | id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 US(840) 1 | | | VeriSign(113733)} | | id-pki | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} | | id-attributes | OBJECT_IDENTIFIER ::= {id-pki attributes(9)} | | id-messageType | OBJECT_IDENTIFIER ::= {id-attributes | | | messageType(2)} | | id-pkiStatus | OBJECT_IDENTIFIER ::= {id-attributes | | | pkiStatus(3)} | | id-failInfo | OBJECT_IDENTIFIER ::= {id-attributes | | | failInfo(4)} | | id-senderNonce | OBJECT_IDENTIFIER ::= {id-attributes | | | senderNonce(5)} | | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes | | | recipientNonce(6)} | | id-transId | OBJECT_IDENTIFIER ::= {id-attributes | | | transId(7)} | | id-extensionReq | OBJECT_IDENTIFIER ::= {id-attributes | | | extensionReq(8)} | +-------------------+-----------------------------------------------+ Appendix C. SCEP State Transitions SCEP state transitions are indexed by the transactionID attribute. The design goal is to ensure the synchronization between the CA and the requester under various error situations. Each enrollment transaction is uniquely associated with a transaction identifier (carried in the transactionID signed attribute (see Section 3.1.1.1). Because the enrollment transaction could be interrupted by various errors, including network connection errors or client reboot, the SCEP client generates a transaction identifier by calculating a hash on the public key value for which the enrollment is requested. This retains the same transaction identifier throughout the enrollment transaction, even if the client has rebooted or timed out, and issues a new enrollment request for the same key pair. It also provides the way for the CA to uniquely identify a transaction in its database. At the requester side, it Nourse & Vilhuber Expires October 3, 2009 [Page 40] Internet-Draft SCEP April 2009 generates a transaction identifier which is included in PKCSReq. If the CA returns a response of PENDING, the requester will poll by periodically sending out GetCertInitial with the same transaction identifier until either a response other than PENDING is obtained, or the configured maximum time has elapsed. If the client times out or the client reboots, the client administrator will start another enrollment transaction with the same key pair. The second enrollment will have the transaction identifier. At the server side, instead of accepting the PKCSReq as a new enrollment request, it should respond as if another GetCertInitial message had been sent with that transaction ID. In another word, the second PKCSReq should be taken as a resynchronization message to allow the enrollment resume as the same transaction. It is important to keep the transaction id unique since SCEP requires the same policy and same identity be applied to the same subject name and key pair binding. In the current implementation, an SCEP client can only assume one identity. At any time, only one key pair, with a given key usage, can be associated with the same identity. The following gives several examples of client to CA transactions. Client actions are indicated in the left column, CA actions are indicated in the right column. A blank action signifies that no message was received. Note that these examples assume that the CA enforces the certificate-name uniqueness property defined in Section 2.1.2.4. The first transaction, for example, would read like this: "Client Sends PKCSReq message with transaction ID 1 to the CA. The CA signs the certificate and constructs a CertRep Message containing the signed certificate with a transaction ID 1. The client receives the message and installs the certificate locally." Successful Enrollment Case: no manual authentication PKCSReq (1) ----------> CA Signs Cert Client Installs Cert <---------- CertRep (1) SIGNED CERT Simple Enrollment Example Nourse & Vilhuber Expires October 3, 2009 [Page 41] Internet-Draft SCEP April 2009 Successful Enrollment Case: manual authentication required PKCSReq (10) ----------> Cert Request goes into Queue Client Polls <---------- CertRep (10) PENDING GetCertInitial (10) ----------> Still pending Client Polls <---------- CertRep (10) PENDING GetCertInitial (10) ----------> Still pending Client Polls <---------- CertRep (10) PENDING GetCertInitial (10) ----------> Still pending Client Polls <---------- CertRep (10) PENDING GetCertInitial (10) ----------> Cert has been signed <---------- CertRep (10) SIGNED CERT Client Installs Cert Enrollment with Pending Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants the certificate and returns SUCCESS, with the certificate. The SUCCESS gets lost: PKCSReq (3) ----------> Cert Request goes into queue <---------- CertRep (3) PENDING GetCertInitial (3) ----------> <---------- CertRep (3) PENDING GetCertInitial (3) -----------> X-------- CA grants Cert CertRep(3) SUCCESS (Time Out) PKCSReq (3) ----------> Cert already granted <---------- CertRep (3) SUCCESS Client Installs Cert Resync Case 1 Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply gets lost: PKCSReq (3) ----------> Cert Request goes into queue X-------- CertRep (3) PENDING (Time Out) PKCSReq (3) ----------> <---------- CertRep (3) PENDING etc... Resync Case 2 Nourse & Vilhuber Expires October 3, 2009 [Page 42] Internet-Draft SCEP April 2009 Case when the Certificate is lost and client has to generate a new key pair, there is no change of name information: PKCSReq (4) ----------> CA Signs Cert <---------- CertRep (4) SIGNED CERT Client Installs Cert (Client looses Cert) PKCSReq (5) ----------> There is already a valid cert with this DN. <---------- CertRep (5) BAD REQUEST Admin Revokes PKCSReq (5) ----------> CA Signs Cert <---------- CertRep (5) SIGNED CERT Client Installs Cert Retrieving lost certificate Appendix D. CA Capabilities D.1. GetCACaps HTTP Message Format "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT This message requests capabilities from CA. The response is a list of text capabilities, as defined in Appendix D.2. Support for this message is optional, but if it is not supported, the client should assume that none of the capabilities in Appendix D.2 are supported. D.2. CA Capabilities Response Format The response for a GetCACaps message is a list of CA capabilities, in plain text, separated by characters, as follows (quotation marks are NOT sent): +--------------------+----------------------------------------------+ | Keyword | Description | +--------------------+----------------------------------------------+ | "GetNextCACert" | CA Supports the GetNextCACert message. | | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP | | | POST. | | "Renewal" | Clients may use current certificate and key | | | to authenticate an enrollment request for a | | | new certificate. | | "SHA-512" | CA Supports the SHA-512 hashing algorithm in | | | signatures and fingerprints. | | "SHA-256" | CA Supports the SHA-256 hashing algorithm in | | | signatures and fingerprints. | Nourse & Vilhuber Expires October 3, 2009 [Page 43] Internet-Draft SCEP April 2009 | "SHA-1" | CA Supports the SHA-1 hashing algorithm in | | | signatures and fingerprints. | | "DES3" | CA Supports triple-DES for encryption. | +--------------------+----------------------------------------------+ The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5 hashing if it is supported by the CA. A client MUST be able to accept and ignore any unknown keywords that might be sent back by a CA. If none of the above capabilities are supported by the CA, a server SHOULD return an empty message. A server MAY simple return an HTTP error. The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore the Content-type, as servers implementing early version of the SCEP draft may send various Content-types. Example: GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca GetCaCaps request might return: GetNextCACertPOSTPKIOperation GetCaCaps reply example This means that the CA supports the GetNextCACert message and allows PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent using HTTP POST. Appendix E. Certificate Renewal and CA Key Rollover To renew a client certificate, use the PKCSreq message and sign it with the existing client certificate instead of a self-signed certificate. To obtain the new CA certificate prior to the expiration of the current one, use the GetNextCACert message if the CA supports it. To obtain a new client certificate signed by the new CA certificate, use the new CA or RA certificate in the message envelope. Example: Nourse & Vilhuber Expires October 3, 2009 [Page 44] Internet-Draft SCEP April 2009 GetNextCACert ----------> <---------- New CA certificate PKCSReq* ----------> CA Signs certificate with NEW key Client Stores Cert <---------- CertRep - Certificate issued for installation when from NEW CA certificate and key pair existing cert expires. *enveloped for new CA or RA cert and key pair. The CA will use the envelope to determine which key and certificate to use to issue the client certificate. GetNextCaCert Transaction Appendix F. PKIOperation via HTTP POST Message If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded SCEP messages may be sent via HTTP POST instead of HTTP GET. This is allowed for any SCEP message except GetCACert, GetNextCACert, or GetCACaps. In this form of the message, Base 64 encoding is not used. POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0 Content-Length: General POST Syntax The client can verify that the CA supports SCEP messages via POST by looking for the "POSTPKIOperation" capability (See Appendix D). Authors' Addresses Andrew Nourse Cisco Systems, Inc 510 McCarthy Drive Milpitas, CA USA Phone: Fax: Email: URI: Nourse & Vilhuber Expires October 3, 2009 [Page 45] Internet-Draft SCEP April 2009 Jan Vilhuber (editor) Cisco Systems, Inc. 510 McCarthy Drive Milpitas, CA USA Email: vilhuber@cisco.com Nourse & Vilhuber Expires October 3, 2009 [Page 46]