INTERNET-DRAFT Rodney Thayer
8 September 1998 EIS Corporation
Expires: 13 March 1998
PKI Requirements for IP Security
draft-ietf-ipsec-pki-req-00.txt
Revision 00, 8 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 it's key
management protocol. This document defines the requirements that
IPSec has for Public Key Infrastructure (PKI) protocols, formats,
and services.
The key words "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.
Thayer Expires March 1999 [Page 1]
IPSec PKI INTERNET-DRAFT 5 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...............................4
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 Fulfillment 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. Authors' Address........................................19
9. References.................................................19
Appendix......................................................21
A. Summary of Formats......................................21
1. Names......................................................21
2. Object Identifiers for Signature Algorithms................21
3. Object Identifiers for Extended Key Usage..................21
Thayer Expires March 1999 [Page 2]
IPSec PKI INTERNET-DRAFT 5 September 1998
B. Copyright Statement........................................22
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.
1.1 Terminology
CA - An organization 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
organization dedicated to this function (a "CA") or it may be
operated by a network management organization within an Intranet.
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.
IKE - IPSec Key Exchange protocol suite, a/k/a ISAKMP, Oakley,
and ISAKMP/Oakley resolution.
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 cert) then calling anything but the top
certificate a root is a misnomer.
Thayer Expires March 1999 [Page 3]
IPSec PKI INTERNET-DRAFT 5 September 1998
EKU "Extended Key Usage" fields in certificate requests and
certificates.
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 a public ("retail")
Certificate Authority or also might be a private entity operating
an appropriate computer system ("certificate engine".)
Intermediate system
End system
Usage certificate
Signing 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, and since these devices are often initialized
before they are ever connected to the network, there is a
requirement to support systems that are isolated from real-time
communcations with a CA (i.e., systems not conected to a network)
for certificate fulfillment and CRL updating. 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.
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
authorization 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
Thayer Expires March 1999 [Page 4]
IPSec PKI INTERNET-DRAFT 5 September 1998
of two IPSec devices and a minimum of one PKI service provider.
In general, each IPSec device has its own PKI service provider
and therefore the abstract minimum configuration has four
parties, the two IPSec parties and the two PKI parties. Therefore
there are a minimum of three and possibly four certificates
involved the two IPSec certificates and one or two PKI root
certificates.
The IPSec device has its own certificate, based on its 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 Fulfillment)
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 its revocation
- Its own certificate
- The root certificate that validates its peer IPSec
component
- Validity checking information (e.g. CRL) to confirm
validation of its peers certificate
In order to provide a cryptographically sound environment, the
PKI MUST provide for the use of at least two public key
technologies. The PKI must provide DSA [DSA] public key support
and MUST provide one other mechanism. The size of the keys
involved are specific to the algorithm, and are specified in
[DSA4IPSec] for the mandatory-to-implement 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
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.
Thayer Expires March 1999 [Page 5]
IPSec PKI INTERNET-DRAFT 5 September 1998
IPSec devices MUST support a signing hierarchy containing at
least eight (8) signing certificates (i.e. an 8 layer root
topology.)
All the certificates used in the IPSec device and the PKI must be
of the same key length.
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 hierarchy to check to validat a peers certificate.
Thayer Expires March 1999 [Page 6]
IPSec PKI INTERNET-DRAFT 5 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 deos 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 fulfillment
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
Thayer Expires March 1999 [Page 7]
IPSec PKI INTERNET-DRAFT 5 September 1998
this format is available for implementors now and is known to
exist in current PKI service provider implementations.
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.
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 5 September 1998
The off-line (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 CRLs or on-line 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
Thayer Expires March 1999 [Page 9]
IPSec PKI INTERNET-DRAFT 5 September 1998
certificate of the issuer in the certification hierarchy and
through other means.
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 sigature 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 must be checked for validity. For
ipAddress, the address MUST be checked to confirm it is valid for
the IKE negotiation in progress. For dNSName the name must be
retrived 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
must 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
Thayer Expires March 1999 [Page 10]
IPSec PKI INTERNET-DRAFT 5 September 1998
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.
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 certificates 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 its
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 5 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" must contain a relevant and valid name
3. "subjectName" must 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 relevent 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 5 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 cert will be used for an end-
node with IPSec and IKE. An "end node" is defined to be an IPSec
device which 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 cert will be used for an
intermediate note with IPSEc and IKE. An "intermediate node" is
definde to be an IPSec device which 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 MUST contain exactly one of
these values:
- ipAddress
- dNSName
- rFC822Name
If the field contains an IP Address, this SHOULD 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 MUST be a valid DNS name that
corresponds to a valid IP address as seen by the IPSec device
Thayer Expires March 1999 [Page 13]
IPSec PKI INTERNET-DRAFT 5 September 1998
processing the certificate. The name must resolve to a single
IPv4 address and the name must not end in a trailing dot.
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 boundries 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 Enrollment Message [BAL-EMS] or
presented as a classic PKCS#10 Certificate Request.
The request SHOULD contain subjectAltName information, althought
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.]
Thayer Expires March 1999 [Page 14]
IPSec PKI INTERNET-DRAFT 5 September 1998
4.3 IPSec Usage Certificate
A certificate which contains the public key component of a 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. An IPSec Usage
Certificate MUST be signed by a key pair which corresponds to a
Signing Certificate and the Signing Certificate MUST be available
for other IPSec devices to validate this signature.
4.4 Signing Certificates
This is a certificate which 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 5 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 5 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 Fulfillment 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
Thayer Expires March 1999 [Page 17]
IPSec PKI INTERNET-DRAFT 5 September 1998
E3exE/kbPGDXCw+36CSruHOIpMvf0o1YBezL2G+MrhEwDbk0n0Kaqpf9jOc4+i2u9
Qlt\
4nck
sgoRdv7TiPp3EkJa3siwSjx+ikyo7oLUa6mWdLn0Wrnm9rVUf0yyQiYc3H6ul7\
Pn9c7oNZ7G
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
implementors and PKI service providers, as well as other members
of the IETF community. It also benefits from the spirit of
Thayer Expires March 1999 [Page 18]
IPSec PKI INTERNET-DRAFT 5 September 1998
interoperability exhibited by participants in the various IPSec
bakeoff events.
7. Security Considerations
[more text required here...]
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.
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.
If you cross-sign signing certificates you run the risk of
leaking trust across hierarchies in unintended ways.
8. 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. References
[PEM] PEM RFC's describing "ASCII Armor" format.
[PKCS #7] RSA PKCS specs
[DOI]
[Arch] IP Security Architecture draft
[DSA] dsa defn as specified in pkix, ietf doc or other?
Thayer Expires March 1999 [Page 19]
IPSec PKI INTERNET-DRAFT 5 September 1998
[DSA4IPSec]
[IKE]
[BAL-EMS] LaMacchia, B. "Enrollment Message Syntax", unpublished
proposal discussed at IPSec Bake-off in Redmond, September 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.
[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 20]
IPSec PKI INTERNET-DRAFT 5 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 64
characters in length.
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 21]
IPSec PKI INTERNET-DRAFT 5 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 13 September 1998.
Thayer Expires March 1999 [Page 22]
