[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
          INTERNET-DRAFT                                      Rodney Thayer
          13 September 1998                                  EIS
          Corporation
          Expires: 18 March 1999
          
                          PKI Requirements for IP Security
                           draft-ietf-ipsec-pki-req-01.txt
                           Revision 01, 13 September 1998
          
          Status of this Memo
          
          This document is an Internet-Draft. 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."
          
          To view the entire list of current Internet-Drafts, please check
          the "1id-abstracts.txt" listing contained in the Internet-Drafts
          Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
          (Northern Europe), ftp.nis.garr.it (Southern Europe),
          munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
          ftp.isi.edu (US West Coast).
          
          Abstract
          
          The IP Security (IPSec) protocol set now being defined in the
          IETF uses public key cryptography for authentication in its key
          management protocol.  This document defines the requirements that
          IPSec has for Public Key Infrastructure (PKI) protocols, formats,
          and services.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999              [Page 1]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          Contents
          Status of this Memo............................................1
          Abstract.......................................................1
          Contents.......................................................2
          1. Introduction................................................3
          1.1   Terminology..............................................3
          2. Environment.................................................4
          2.1 PKI Environment Requirements...............................5
          2.2 Authentication Topology Requirements.......................5
          3. Processes...................................................7
          3.1 Fulfillment................................................7
          3.1.1 Certificate Request Creation.............................7
          3.1.2 Certificate Delivery.....................................8
          3.2 Retrieval..................................................9
          3.3 Validation.................................................9
          3.4 Management................................................10
          3.4.1 Certificate Issuance....................................10
          3.4.2 Revocation of Certificate Validity......................11
          3.4.3 IPSec validity checking.................................12
          3.5 IKE Processing of Certificates............................12
          4. Formats....................................................13
          4.1 Certificate Format Component Details......................13
          4.1.1 IPSec EKU Object Identifiers............................13
          4.1.2 subjectAltName Name Format..............................13
          4.1.3 Key Sizes...............................................14
          4.1.4 Certificate Request and Certificate Formats.............14
          4.1.5 Object Identifiers......................................14
          4.2 Certificate Request.......................................14
          4.3 IPSec Usage Certificate...................................15
          4.4 Signing Certificates......................................15
          4.4.1 Root Signing Certificate................................15
          4.4.2 Intermediate Signing Certificate........................15
          4.5 Certificate Revocation List...............................16
          5. Samples....................................................17
          5.1 Certificate Fulfilment Request............................17
          5.2 IPSec Usage Certificate...................................17
          5.3 Signing Certificate.......................................18
          5.4 Certificate Revocation List...............................18
          6. Acknowledgements...........................................18
          7. Security Considerations....................................19
          8. IANA Considerations........................................19
          9. Colophon...................................................19
          9.1 Authors' Address..........................................19
          9.2 About this document.......................................19
          9.3 Change History............................................20
          10. References................................................20
          Appendix......................................................22
          A. Summary of Formats.........................................22
          1. Names......................................................22
          2. Object Identifiers for Signature Algorithms................22
          3. Object Identifiers for Extended Key Usage..................22
          Thayer                 Expires March 1999              [Page 2]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          B. Copyright Statement........................................23
          
          1. Introduction
          
          This document describes the Public Key Infrastructure facilities
          required to support IPSec [Arch]. It is the intention of this
          document to describe the mechanisms that are to be used today to
          support certificate use in IPSec implementations, and to specify
          how PKIX [PKIX-1, etc.] MUST be used in the future to support
          IPSec.
          
          The document discusses the (IPSec) environment in which
          certificates will be used including the way certificates are
          used, the processing involved, and the requirements for support
          from a PKI.
          
          The key words "MUST", "SHALL", "REQUIRED", "SHOULD",
          "RECOMMENDED", and "MAY" in this document are to be interpreted
          as described in RFC 2119.
          
          Please send comments on this document to the ipsec@tis.com
          mailing list.
          
          
          1.1  Terminology
          
          
          CA - An organisation that issues certificates signed by some
          hierarchy.
          
          CA Engine - a machine or mechanism or software package used for
          the process of signing certificates. This may be operated by an
          organisation dedicated to this function (a "CA") or it may be
          operated by a network management organisation within an Intranet.
          
          commonName –- see [PKIX-1] for definition of this and other PKIX
          data structure field names.
          
          countryName --see [PKIX-1] for definition of this and other PKIX
          data structure field names.
          
          CRL - A Certificate Revocation List, in the PKIX sense of the
          term.
          
          Device Identification Certificate -- a certificate issued to an
          IPSec-aware device such as a router, gateway, VPN device, or end
          system. Note these devices are not necessarily associated with a
          specific person and therefore naming schemes such as email
          address are not appropriate.
          
          
          
          Thayer                 Expires March 1999              [Page 3]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          EKU – "Extended Key Usage" fields in certificate requests and
          certificates.
          
          End system
          
          IKE - IPSec Key Exchange protocol suite, a/k/a ISAKMP, Oakley,
          and ISAKMP/Oakley resolution.
          
          Intermediate system
          
          Root Certificate –- A 'Root' Signing Certificate is also
          sometimes referred to as a self-signed certificate.
          
          Signing Certificate -- a certificate containing the public key
          portion of a key pair, where the certificate was used to sign
          another certificate. In an exactly two-layer hierarchy there is a
          "root" signing certificate and there are subject certificates.
          This term is used because if there are hierarchies (e.g. root1 ->
          root2 -> root3 -> subject certificate) then calling anything but
          the top certificate a root is a misnomer.
          
          PKI service provider – the software that issues certificates by
          signing the public key and other information delivered to it in a
          certificate request.  This might be operated by a public
          ("retail") Certificate Authority or also might be a private
          entity operating an appropriate computer system ("certificate
          engine".)
          
          Signing certificate
          
          subjectAltName –- see [PKIX-1] for definition of this and other
          PKIX data structure field names.
          
          subjectName –- see [PKIX-1] for definition of this and other PKIX
          data structure field names.
          
          Usage certificate
          
          
          
          2. Environment
          
          
          IPSec runs in both an end-system and a gateway environment. These
          systems may or may not be attended or associated with a person.
          IPSec devices may well represent a site's only link to the
          outside world.  Since these devices are often initialised before
          they are ever connected to the network, there is a requirement to
          support systems that are isolated from real-time communications
          with a PKI service provider.  Devices which implement IPSec may
          or may not be connected to the public Internet and cannot be
          assumed to have local mass storage or removable media.
          
          Thayer                 Expires March 1999              [Page 4]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          When IPSec uses a PKI it may be any combination of public and
          private certifying authorities. This manifests itself as a
          requirement to have available locally a copy of one or more root
          certificate for signature verification.
          
          The PKI environment used by IPSec may provide a variety of
          authorisation topologies; these are discussed in section 2.2.
          
          2.1 PKI Environment Requirements
          
          The relationship between an IPSec device and the PKI it uses is
          one of a client and a service provider. In this case the client
          is the IPSec device, and the service provider is the PKI
          provider. The IPSec device, by definition, is interacting with at
          least one other IPSec device, and therefore there are a minimum
          of two IPSec devices and a minimum of one PKI service provider.
          At times, each IPSec device has it’s own PKI service provider and
          therefore the abstract minimum configuration has four parties,
          the two IPSec parties and the two PKI parties. Therefore there is
          a minimum of three and possibly four certificates involved – the
          two IPSec certificates and one or two PKI root certificates.
          
          The IPSec device has it’s own certificate, based on it’s own
          public and private key pair. The generation of the key pair (i.e.
          was it generated inside or outside the IPSec device, is it backed
          up, etc.) is outside of the scope of this document. In order to
          establish this certificate, the PKI environment must support the
          processes needed to support this. Sections 3.1 (PKI Fulfilment)
          and 3.2 (PKI Retrieval) describe these processes. These processes
          are used to get the IPSec the certificates it requires for
          processing by the IKE [IKE] component. This means the IPSec
          device requires this:
          
            - A mechanism to request a certificate and it’s revocation
            - It’s own certificate
            - The root certificate that validates it’s peer IPSec
               component
            - Validity checking information (e.g. CRL) to confirm
               validation of it’s peer’s certificate
          
          In order to provide a cryptographically sound environment, the
          PKI SHOULD provide for the use of at least two public key
          algorithms. The PKI must provide DSA [DSA] public key support and
          SHOULD provide at least one other mechanism. The size of the keys
          involved is specific to the algorithm.
          
          2.2 Authentication Topology Requirements
          
          The PKI provides to the IPSec device a hierarchy of signing
          certificates, terminated at a root certificate. There MUST be a
          Thayer                 Expires March 1999              [Page 5]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          minimum of one signing certificate and it MUST be used to confirm
          that a certificate received from an IPSec peer is valid. A given
          IPSec device MUST have available to it some set of trustable
          signing certificates, which are used to validate a certificate,
          received from a peer IPSec device. This set of signing
          certificates must be made available to the IPSec device in a
          secure manner, e.g. manually loaded, because they are the basis
          for the trust that is inherited by the incoming certificates.
          
          IPSec devices MUST support a signing hierarchy containing at
          least eight (8) signing certificates (i.e. an 8 layer root
          topology.)
          
          Each peer IPSec device MAY be associated with a different signing
          hierarchy and therefore the IPSec device SHOULD support multiple
          signing hierarchies. Also, each IPSec device MAY have multiple
          identity certificates issued by different signing hierarchies.
          
          It is outside the scope of this document to determine how an
          IPSec device will determine which of its certificates to use or
          which signing hierarchies to check to validate a peer's
          certificate.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999              [Page 6]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          
          
          3. Processes
          
          
          This section describes the processes that must be supported to
          provide certificates and in general PKI support for IPSec
          devices. Section 3.1 describes the processes to be supported to
          request a certificate for an IPSec device, section 3.2 describes
          the processes to be supported to retrieve certificates for use by
          IPSec devices, section 3.3 describes the processes to be
          supported to determine the validity of a given certificate,
          section 3.4 describes the certificate management processes to be
          supported.
          
          
          3.1 Fulfillment
          
          
          Note that some request formats may require manual processing by
          the CA (i.e., PKCS#10 does not support all X509v3 extensions. Use
          of those extensions may require the CA to manually enter
          extension data into the certificate request.
          
          Note that edge devices such as routers may use their network
          management capabilities to facilitate this, e.g. the management
          station may be the one to email the certificate fulfilment
          request to the CA.
          
          3.1.1 Certificate Request Creation
          
          In order to initially establish a certificate for an IPSec device
          there must be a certificate request generated by or on behalf of
          the IPSec device and delivered to the some entity within the PKI
          service provider. This involves these steps:
          
            1. A public/private key pair is obtained
            2. A certificate request data message is constructed
            3. The certificate request is delivered to the PKI service
               provider
          
          The public private key pair is obtained through some mechanism
          outside of this document.
          
          The certificate request can be constructed in one of two formats.
          These are PKCS #10 [PKCS-10] or PKIX (Part 3) [PKIX-3.]  PKCS
          #10, although not an IETF document, is a format that already has
          effective ‘best current practice’ status in the PKI community and
          this format is available for implementers now and is known to
          exist in current PKI service provider implementations.
          
          
          
          Thayer                 Expires March 1999              [Page 7]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          The PKCS #10 certificate request format MUST be supported. When
          this is used, the value to be placed in the subjectAltName and
          the fact this certificate is to be used for IPSec must be
          communicated to the PKI service provider in an out-of-band
          manner.
          
          The PKIX Part 3 Certificate Request format ('CertReqMsg' from
          [CRMF]) SHOULD be used in the future to request a certificate for
          IPSec usage. There MUST be an Extended Key Usage Extension
          containing an iKEEnd or iKEIntermediate entry, and the
          subjectAltName MUST be set to an appropriate value. See section
          4.1.1 for a description of iKEEnd and iKEIntermediate.
          
          In either case the certificate generated by the PKI service
          provider MUST contain the subjectAltName specified and MAY NOT be
          changed.  If for whatever reason (policy, CPS, technical reasons,
          etc.) the certificate request is not acceptable to the PKI
          service provider, it MUST NOT issue a certificate for this
          certificate request.  In addition, the PKI service provider
          SHOULD use the same subjectName as was supplied in the request
          and SHOULD NOT change it.  If the subjectName provided was not
          acceptable to the PKI service provider, or if a change-of-name
          PKI policy is not mutually acceptable, the certificate request
          SHOULD be rejected.  In other words, the IPSec Usage Certificate
          that comes back should have a subjectName that is acceptable and
          expected.
          
          3.1.2 Certificate Delivery
          
          In order to deliver this certificate request to the PKI service
          provider, there are several possible mechanisms. At this time,
          best current practice does not include any automated mechanisms.
          Therefore we must specify what delivery schemes are expected to
          be used for an IPSec device.
          
          In the case of a PKCS #10 request, the request itself MUST be
          encoded as either DER or PEM format. It MAY be made available to
          the PKI service provider as one of:
          
            - text file suitable for email delivery
            - disk file suitable for removable media transmission (e.g.
               overnight shipment with documented receipt)
            - on-line delivery via ad hoc mechanism (e.g. web form, shared
               disk directory, FTP, or email)
          
          In the case of a PKIX request, the request itself is formatted
          according to the rules of PKIX. A CertReqMsg is delivered through
          one of the standard PKIX mechanisms, including offline and online
          PKIX formats.
          
          
          Thayer                 Expires March 1999              [Page 8]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          The offline (file based) PKCS #10 PEM formatted request mechanism
          MUST be supported by the IPSec device and the PKI service
          provider. It is outside the scope of this document to specify how
          the IPSec device is to produce a file containing the request.
          However it is assumed that IPSec devices will use their
          associated network management facilities to produce such a file.
          
          
          3.2 Retrieval
          
          
          While a network is operating using IPSec the certificates
          provided by the PKI are used for IKE identification purposes, and
          thus are indirectly used for key exchange. The IPSec-aware
          devices have a requirement to retrieve and to share device
          identification certificates, signing certificates, and
          certificate validity information.
          
          IPSec devices MUST be able to retrieve their own fulfilled
          certificates, signing certificates for other IPSec devices, and
          identification certificates for other IPSec devices. An
          identification certificate which identifies an IPSec device must
          be loaded into that device in a secure manner.
          
          A signing certificate which is used to validate other IPSec
          devices’ identification certificates must be loaded in a secure
          manner. It should not be retrieved through an unsecured network
          mechanism, for example, or accepted if received as an IKE
          certificate payload.
          
          Identification certificates received from IPSec devices through
          IKE or through other means MUST be validated using signing
          certificates and MAY be validated using other means to detect
          revoked certificates, such as CRL’s or online directories. IPSec
          devices MUST be able to accept identification certificates sent
          through IKE and they also MUST be able to accept certificates
          through some other mechanism, such as manual loading, or some
          PKIX protocol.
          
          These certificates which are received MAY be in PKCS #7 format,
          DER or PEM encoded, unencrypted (see Section 4.3.1) or MAY be in
          some standard PKIX format (see section 4.3.2).
          
          
          3.3 Validation
          
          
          Certificates as used for IPSec are validated using the signature
          certificate of the issuer in the certification hierarchy and
          through other means.
          
          
          
          Thayer                 Expires March 1999              [Page 9]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          After checking to ensure the certificate is not malformed, the
          signature should be checked. (See Section 6 of [PKIX-part1] for a
          brief tutorial on certification path validation.)  In order for a
          Signature certificate to be used for verification, the
          certificate(s) must be pre-loaded within the IPSec devices, or
          retrieved in a secure manner.
          
          After determining the signature is valid, the fields of the
          certificate SHOULD be checked.  If all these fields are not
          checked, the IPSec implementation MUST document what checking is
          done so that the level of security provided by the implementation
          can be determined.
          
          Certificate contents to be checked are:
          
            1. Signature through chain as described above
            2. Date.  This SHOULD be year-2000 compliant by using
               GeneralTime to provide four digit years.
            3. ExtendedKeyUsage SHOULD be checked to ensure the certificate
               is valid for the system in question, including the
               criticality fields.  This extension MUST be treated as
               critical.
            4. subjectAltName validation checking (see below)
          
          The subjectAltName field MAY be checked for consistency.  For
          ipAddress, the address MAY be checked to confirm it is valid for
          the IKE negotiation in progress.  For dNSName the name MAY be
          retrieved from the DNS to validate it is valid for the IP address
          which was the source of the certificate, if known, and for the
          IKE negotiation in progress.  For rFC822Name, the email address
          MAY be checked according to the style of SMTP to ensure email
          name validity.
          
          
          3.4 Management
          
          
          The term "manangement" as used here means the processes used for
          the creation, validity determination, and destruction of
          certificates.
          
          3.4.1 Certificate Issuance
          
          Certificates SHOULD be issued only for certificate requests that
          contain a valid Extended Key Usage extension in the certificate
          request. The certificate that is issued SHOULD contain the same
          Extended Key Usage object identifier as the request contained.
          If the certificate request contains a subjectAltName extension
          then the certificate MUST contain the same subjectAltName
          extension.  If the PKI service provider cannot meet these
          requirements then it MUST NOT issue the certificate.
          
          Thayer                 Expires March 1999             [Page 10]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          Certificate requests may be delivered to the PKI service provider
          through either PKCS #10, CMC, or PKIX mechanisms and the
          resultant certificate may be delivered through any of the
          corresponding mechanisms.  In all cases the certificate request
          and resultant certificate SHOULD be delivered through an
          appropriately secure mechanism.
          
          3.4.2 Revocation of Certificate Validity
          
          At any time the PKI service provider can revoke the validity
          status of a certificate it has issued.  The process of requesting
          this revocation is outside of the scope of this document.  Once
          the certificate’s status has changed from valid to invalid, IPSec
          devices that use these certificates MUST NOT use these
          certificates if they are aware they are no longer valid.  The
          process of determining whether a given certificate is valid is
          outside the scope of this document.  An IPSec device SHOULD use
          some mechanism to determine if a certificate has had it’s
          validity revoked before it is used.  The IPSec device may use
          Certificate Revocation Lists, on-line directories, or other
          mechanisms.  These mechanism MUST be used in a secure manner,
          i.e. some scheme MUST be used to secure the revocation
          information such as signing certificate signatures on a CRL.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 11]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          3.4.3 IPSec validity checking
          
          IKE implementations must check the certificate for validity at
          the time it is used, e.g. at Main Mode initiation time.  The
          certificate MUST be checked for field validity and for semantic
          validity.  The fields that MUST be checked are:
          
            1. NotBefore and notAfter times must be valid
            2. "subjectAltName" MAY contain a relevant and valid name
            3. "subjectName" SHOULD be non-empty
            4. if extendedKeyUsage is present it must contain either
               iKEIntermediate or iKEEnd.  If additional EKU object
               identifiers are present then their use is a locally defined
               matter.
            5. keyUsage MAY be checked for locally defined valid
               combinations
            6. the signature of the certificate must be checked against
               signing certificate hierarchy
          
          IKE implementations MUST examine the not-after time in
          conjunction with all relevant SA lifetimes (both IKE SA and IPSec
          SA's) at the time the certificate is used to authenticate
          creation of an SA. If the SA would definitely expire after the
          end of the certificate lifetime then the SA MUST NOT be created.
          If an IPSec device learns that a certificate used in association
          with the creation of an IKE or an IPSec security association
          becomes invalid for any reason the corresponding security
          association MUST be deleted.
          
          3.5 IKE Processing of Certificates
          
          [something about cert requests]
          
          [something about 'signature' vs. digital encipherment"]
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 12]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          
          
          4. Formats
          
          
          This section describes the fields required in the various
          certificate-related messages, as they are used for IPSec.
          
          
          4.1 Certificate Format Component Details
          
          
          4.1.1 IPSec EKU Object Identifiers
          
          The OID "iKEEnd"
          (iso.org.dod.internet.security.ipsec.certificate.2, or
          1.3.6.1.5.5.8.2.2) declares this certificate will be used for an
          end-node with IPSec and IKE.  An "end node" is defined to be an
          IPSec device that does not offer IPSec services on behalf of
          other devices such as a server or desktop system.
          
          The OID "iKEIntermediate"
          (iso.org.dod.internet.security.ipsec.certificate.2, or
          1.3.6.1.5.5.8.2.2) declares this certificate will be used for an
          intermediate note with IPSec and IKE.  An "intermediate node" is
          defined to be an IPSec device that offers IPSec services on
          behalf of other devices e.g. using tunnel mode and IP forwarding.
          
          4.1.2 subjectAltName Name Format
          
          For IPSec devices the actual name of the subject is stored in the
          subjectAltName field.  This field SHOULD contain exactly one of
          these values:
          
            - ipAddress
            - dNSName
            - rFC822Name
          
          If the field contains an IP Address, this MUST be one single IPv4
          address, expressed as four bytes in network order.  Other uses of
          this field such as Ipv6 or subnetwork address are not allowed.
          Note the address must be checked for validity and not for
          connectivity, that is, it is not necessary that there be a path
          from the IPSec device to this address but rather it is necessary
          that this IPSec device make an explicit decision that this is a
          valid address.
          
          If the field contains a DNS name it SHOULD be a valid DNS name
          that corresponds to a valid IP address as seen by the IPSec
          device processing the certificate.  The name SHOULD resolve to a
          single IPv4 address and the name MUST NOT end in a trailing dot.
          
          
          Thayer                 Expires March 1999             [Page 13]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          If the field contains an RFC 822 name it must be a valid email
          address which the IPSec device may assume is accessible.
          
          4.1.3 Key Sizes
          
          1024 bit keys or equivalent must be supported.
          
          4.1.4 Certificate Request and Certificate Formats
          
          Certificate requests and certificates MAY be exchanged in either
          raw binary ("DER") format or in encapsulated Base-64 format in
          the style of PEM [RFC-1421].  Encapsulated Base-64 format means:
          
               - first line SHOULD contain "-----BEGIN CERTIFICATE-----"
                 or "-----BEGIN CERTIFICATE REQUEST-----"
               - Certificate or certificate request, encoded as per [RFC-
                 1421] (64 characters per line)
               - Last line SHOULD contain "-----END CERTIFICATE-----" or
                 "-----END CERTIFICATE REQUEST-----"
          
          The use of the begin and end delimiters is in the style of PEM
          but uses the pre- and post-encapsulating boundaries first
          developed by Netscape and now in common use [Weinstein.]
          
          4.1.5 Object Identifiers
          
          The object identifier used to identify RSA encryption with SHA-1
          Hashing SHOULD be 1.3.14.3.2.29, i.e. the ISO variant.
          
          
          4.2 Certificate Request
          
          
          A Certificate request is used to provide a public key and
          associated naming information for an IPSec device to a PKI
          service provider.  The request itself MUST be a
          'CertificationRequest' structure as defined in [RFC-2314].  This
          MAY be encapsulated in a PKIX Enrolment Message [BAL-EMS] or
          presented as a classic PKCS#10 Certificate Request.
          
          The request SHOULD contain subjectAltName information, although
          that may be provided out of band.  If subjectAltName is provided
          it is stored in the 'attributes' field of the
          CertificationRequest structure.  The attributes are defined using
          the "Extensions" format defined in [PKIX-1.]  Alternatively and
          for backwards compatability, the TIPEM/BCERT style of 'T-61
          string' encoding MAY be used although this format should be
          avoided if possible. [more clear wording awaiting response from
          RSA...]
          
          
          
          Thayer                 Expires March 1999             [Page 14]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          The request MUST contain some information in the subjectName
          field.  The exact contents of this field are not standardized.
          By convention, a minimal subjectName contains countryName and
          commonName.
          
          
          4.3 IPSec Usage Certificate
          
          
          A certificate that contains the public key component of a key
          pair used to identify an IPSec device is called an "IPSec Usage
          Certificate".  This certificate is in the format described in
          [PKIX-Part1] as a 'Certificate' containing a 'TBSCertificate'.
          The 'extensions' field of the TBSCertificate SHOULD be present.
          One of the EKU attributes SHOULD be present as an extension.  One
          subjectAltName attribute SHOULD be present.  There SHOULD NOT be
          more than one subjectAltName attribute present.  A key pair that
          corresponds to a Signing Certificate MUST sign an IPSec Usage
          Certificate and the Signing Certificate MUST be available for
          other IPSec devices to validate this signature.
          
          
          4.4 Signing Certificates
          
          
          This is a certificate that contains the public key component of
          the key pair used to sign IPSec Usage Certificates. The only
          relevant fields are the subjectName and the public key. IKE
          implementations MUST use the subjectName of Signing Certificates
          to match the issuerName of any certificate that is being checked.
          
          Signing certificates MAY have the CA bit set in their key usage
          field and SHOULD have EKU attributes identifying them as capable
          of signing IPSec certificates.  The same two OID's are used for
          signing certificates as for IPSec usage certificates.
          
          Signing Certificates use the same format from [PKIX-1] as Usage
          Certificates.
          
          4.4.1 Root Signing Certificate
          
          A 'Root' Signing Certificate is one in which the subjectName and
          issuerName fields contain the same distinguished name.
          
          4.4.2 Intermediate Signing Certificate
          
          This is a certificate used to sign other certificates. At this
          time the only relevant fields are the subjectName and the public
          key. IKE implementations MUST use the subjectName of the signing
          certificate to match the issuerName of any certificate that is
          being checked.
          
          
          Thayer                 Expires March 1999             [Page 15]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          4.5 Certificate Revocation List
          
          
          A CRL for IPSec looks just like a CRL as defined in PKIX.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 16]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          
          
          5. Samples
          
          
          This section contains sample PKI objects for interoperability
          testing. These are formatted in PEM or hex dumps of DER encoding.
          
          
          5.1 Certificate Fulfilment Request
          
          
          This is a request from commonName "10.0.0.1" with a 1024 bit key.
          
          -----BEGIN CERTIFICATE REQUEST-----
          MIIBmDCCAQECAQAwWDERMA8GA1UEAxMIMTAuMC4wLjExITAfBgNVBAoTGFZQTmV0
          IFRlY2hub2xvZ2llcywgSW5jLjETMBEGA1UECBMKQ2FsaWZvcm5pYTELMAkGA1UE
          BhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALYF9xDiUoZ/vIeDnhKF
          7pX0cLSv4m3dLDiS9dhqi0zS1SWUPbN3vaeDUkcK+w0mPh4FJXTzum4cy1I0qIv3
          j9a6cPjubWj3XLyGVaJrpTRpnhXdxvR+njGeZpMDTGKgE+5uWbnxs97FfQI+MPTE
          AUC3HoW7I+0bqNihhb1HLIN3AgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAagHsf
          Nsc4u8RhEOo+FN5zfYOCdpXRZulNbU7Fn1qubHrWPDA0eUk6YP86MBzeNQa8wKqz
          0wVCU448wd78NuszYoHeE/C2uAy/taefbShPDZ68dumK3L1j9BEaNv/+6yt31mV7
          BTfAnw5xMLbD5V/RBQ2tWsrPxUdAXEWCJfj/cw==
          -----END CERTIFICATE REQUEST-----
          
          5.2 IPSec Usage Certificate
          
          
          This is a certificate for commonName "10.0.8.1" signed by the
          signing key in section 5.3. (to fit the lines in this document
          '\' was inserted where lines were split.)
          
          -----BEGIN CERTIFICATE-----
          MIICQTCCAesCBQCYAvAMMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\
          ELMAkGA1UE
          CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\
          9neSBDb3Jw
          b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\
          N0b3JhdGUx
          DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\
          VjaC5jb20w
          HhcNOTgwMjAzMDUwMDAwWhcNOTkwMjAzMDQ1OTU5WjBYMREwDwYDVQQDEwgxMC\
          4wLjguMTEh
          MB8GA1UEChMYVlBOZXQgVGVjaG5vbG9naWVzLCBJbmMuMRMwEQYDVQQIEwpDYW\
          xpZm9ybmlh
          MQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsBktyH\
          noHqADQ4IP
          E3exE/kbPGDXCw+36CSruHOIpMvf0o1YBezL2G+MrhEwDbk0n0Kaqpf9jOc4+i2u9
          Qlt\
          4nck
          sgoRdv7TiPp3EkJa3siwSjx+ikyo7oLUa6mWdLn0Wrnm9rVUf0yyQiYc3H6ul7\
          Pn9c7oNZ7G
          
          Thayer                 Expires March 1999             [Page 17]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          KSZ1G4ILitkCAwEAATANBgkqhkiG9w0BAQQFAANBANveH7jw9U8yJPCcAmG7Lq\
          h7f03ALEF/
          SNfp5fHGo1UeeZiMFP7fNBS2oAlqNRDMCWJJnp+EXahaOjqDqTuqS9o=
          -----END CERTIFICATE-----
          
          5.3 Signing Certificate
          
          
          -----BEGIN CERTIFICATE-----
          MIICXDCCAgYCBQCYAvABMA0GCSqGSIb3DQEBBAUAMIG2MQswCQYDVQQGEwJVUz\
          ELMAkGA1UE
          CBMCTUExDzANBgNVBAcTBk5ld3RvbjElMCMGA1UEChMcU2FibGUgVGVjaG5vbG\
          9neSBDb3Jw
          b3JhdGlvbjEsMCoGA1UECxMjU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgRGlyZW\
          N0b3JhdGUx
          DzANBgNVBAMTBmRldi1jYTEjMCEGCSqGSIb3DQEJARYUcm9kbmV5QHNhYmxldG\
          VjaC5jb20w
          HhcNOTgwMjAxMDUwMDAwWhcNOTgwNjAyMDQ1OTU5WjCBtjELMAkGA1UEBhMCVV\
          MxCzAJBgNV
          BAgTAk1BMQ8wDQYDVQQHEwZOZXd0b24xJTAjBgNVBAoTHFNhYmxlIFRlY2hub2\
          xvZ3kgQ29y
          cG9yYXRpb24xLDAqBgNVBAsTI1NlY3VyaXR5IEluZnJhc3RydWN0dXJlIERpcm\
          VjdG9yYXRl
          MQ8wDQYDVQQDEwZkZXYtY2ExIzAhBgkqhkiG9w0BCQEWFHJvZG5leUBzYWJsZX\
          RlY2guY29t
          MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOv2J79yGQG6nb+KCFzNseNpWeFMD7\
          d1NTeFtEqK
          iYhiHbm3y/qoX5bMJDXp3c5EMhRF4akpl+51oAPzYoE4tZ0CAwEAATANBgkqhk\
          iG9w0BAQQF
          AANBAG3g34T44uP3lK1H1ngyXPN79hu50wF9eiknaSzZ6RNEBeM2flgjQYseC/\
          WHlku01UFh
          bg0WAvl/WWeesm4dHtc=
          -----END CERTIFICATE-----
          
          5.4 Certificate Revocation List
          
          
          
          6. Acknowledgements
          
          
          This document was based on discussions with various IPSec
          implementers and PKI service providers, as well as other members
          of the IETF community.  It also benefits from the spirit of
          interoperability exhibited by participants in the various IPSec
          bakeoff events.
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 18]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          7. Security Considerations
          
          
          Check the current literature for recent changes in the known
          safety of the algorithms mentioned here, including MD5, SHA-1,
          RSA, and DSA.
          
          You have to store the private key(s) safely.  If you use keys of
          varying lengths, such as a 512-bit RSA root with 1024-bit usage
          certificate, there may be implications as to the security of your
          infrastructure.
          
          Root or other Signing Certificates should be obtained in a secure
          manner, probably NOT sent over the IKE exchange or from a
          directory, in order to make sure you are not checking against a
          spoofed root.  The distinguished name in a signing certificate
          cannot be assumed to be unique or correct.
          
          Names in certificates, such as IP addresses or FQDN's should be
          checked for consistency with other information about the security
          associations being formed.
          
          If you cross-sign signing certificates you run the risk of
          leaking trust across hierarchies in unintended ways.
          
          8. IANA Considerations
          
          Two new object identifiers are added in this draft, which will be
          submitted to IANA for inclusion in the SMI OID area, see
          www.iana.org for more information.
          
          
          9. Colophon
          
          
          9.1 Authors' Address
          
          Rodney Thayer
          EIS Corporation
          1520 Gulf Blvd #1507
          Clearwater FL 33767
          rodney@unitran.com
          +1 727 560 1947
          http://wg.unitran.com/ietf-ipsec
          
          9.2 About this document
          
          Document edited with Word '98, printed to 'generic text only
          printer' on Windows NT, post-processed to fix Carriage
          Return/Line Feed issues with custom code.  Spell checker
          configured for UK English.
          
          
          
          Thayer                 Expires March 1999             [Page 19]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          9.3 Change History
          
          This is revision 01 of draft-ietf-ipsec-pki-req-<nn>.txt.  This
          version was spell-checked and certain other typographical errors
          were corrected.  The reference to key lengths all being the same
          was removed.  The last two paragraphs of the abstract were moved
          to the introduction.  The dates in the headers, footers, and
          first and last page were updated. The text was changed so the
          validation requirements on subjectAltName fields are listed as
          "SHOULD" and "MAY" and not "MUST" operations.  Chapter 3 was
          changed significantly to reflect the existance of RFC2314 (IETF
          version of PKCS#10) and to clarify some points about the
          processes. The Security Considerations section has been updated
          to reflect these various changes.  Added and updated terms
          section.  Changed two-algorithm requirement to a SHOULD and made
          it more clear.
          
          This document was originally distributed in April 1998 under a
          different name.  There was a second version, distributed at the
          September 1998 IPSec Bakeoff in Redmond at Microsoft.
          
          
          
          10. References
          
          
          [PKCS #7] RSA PKCS specs
          
          [DOI]
          
          [Arch] IP Security Architecture draft
          
          [DSA] dsa defn as specified in pkix, ietf doc or other?
          
          [IKE]
          
          Xxx
          
          [BAL-EMS] LaMacchia, B. "Enrollment Message Syntax", unpublished
          proposal discussed at IPSec Bake-off in Redmond, September 1998.
          
          [DNS-TEST] Eastlake, D., "Reserved Top Level DNS Names", draft-
          ietf-dnsind-test-tlds-11.txt, July 1998.
          
          [PKIX-1] Housley, R. (SPYRUS), Ford, W. (VeriSign), Polk, W.
          (NIST), Solo, D. (Citicorp), "Internet X.509 Public Key
          Infrastructure, Certificate and CRL Profile", draft-ietf-pkix-
          ipki-part1-09.txt, July 28, 1998.
          
          [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
          Mail: Part I: Message Encryption and Authentication Procedures",
          RFC-1421, February 1993.
          
          Thayer                 Expires March 1999             [Page 20]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          [RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax
          Version 1.5"
          
          [Weinstein] Weinstein, J., Private communication regarding "-----
          BEGIN CERTIFICATE-----", September 1998.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 21]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          Appendix
          
          A. Summary of Formats
          
          1. Names
          
          Distinguished Names SHOULD be no more than four (4)
          attribute/value pairs each of which SHOULD be no more than 128
          characters in length, or the length specified in [PKIX-1],
          whatever is shorter.
          
          2. Object Identifiers for Signature Algorithms
          
          SHA-1 with RSA Signature should use the ISO OID, 1.3.14.3.2.29.
          
          3. Object Identifiers for Extended Key Usage
          
          The OID "iKEEnd"
          (iso.org.dod.internet.security.ipsec.certificate.2, or
          1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an
          end system.
          
          The OID "iKEIntermediate"
          (iso.org.dod.internet.security.ipsec.certificate.2, or
          1.3.6.1.5.5.8.2.2) identifies an IPSec Usage Certificate for an
          intermediate system.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 22]


          IPSec PKI           INTERNET-DRAFT          13 September 1998
          
          
          B. Copyright Statement
          
          Copyright (C) The Internet Society (date). All Rights Reserved.
          
          This document and translations of it may be copied and furnished
          to others, and derivative works that comment on or otherwise
          explain it or assist in its implementation may be prepared,
          copied, published and distributed, in whole or in part, without
          restriction of any kind, provided that the above copyright notice
          and this paragraph are included on all such copies and derivative
          works. However, this document itself may not be modified in any
          way, such as by removing the copyright notice or references to
          the Internet Society or other Internet organizations, except as
          needed for the purpose of developing Internet standards in which
          case the procedures for copyrights defined in the Internet
          Standards process shall be followed, or as required to translate
          it into languages other than English.
          
          The limited permissions granted above are perpetual and will not
          be revoked by the Internet Society or its successors or assigns.
          This document and the information contained herein is provided on
          an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
          IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
          IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
          PURPOSE.
          
          
          
                          This draft expires 18 March 1999.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Thayer                 Expires March 1999             [Page 23]