[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

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
                                         <------------------------------
       ................ <manual identity authentication>...............

       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"<BER-encoded X.509>

                          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"<BER-encoded PKCS7>

                          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"<BER-encoded CertRep msg>

                              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"
   <BER-encoded SignedData<BER-encoded degenerate PKCS7>>

                           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 <LF> 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:
   GetNextCACert<LF>POSTPKIOperation

                          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: <length of data>

   <binary PKCS#7 data>

                            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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/