[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PKIX Profile for IKE - CA Certificates & IKE Identification Certificates
More food for thought, and hopefully also for comment! As Paul
Hoffman mentioned in his note earlier today, I am one of the authors
who felt that more detail is needed. To give the group a feel
for how much detail I would like to see, I will attach sample text
for several topics, each within separate postings. This posting
deals with definitions and requirements relevant to the various
public-key certificates used within IKE.
I feel that the topic of how IKE integrates various Certification
Authorities and the related public key certificates into its
operations should be defined in greater detail in "A PKIX Profile
for IKE" (draft-ietf-ipsec-pki-req-03.txt). I propose that we
explicitly define the various types of CA, their roles w/r/t IKE,
and certification hierarchies. Below is some suggested text that
addresses these issues.
_________________SUGGESTED TEXT________________________________
(I use "N" to represent a new section number, should we decide to include
the suggested text into the document.)
N Types of CA: Root, Top, Subordinate, and Intermediate
The profile defined in this document relies on the distinctions between
a "Root CA", a "Top CA", and a "Subordinate CA". The definitions of
these terms have been discussed extensively within the PKIX Working
Group, and have been stabilized in [ROADMAP]. These definitions are
reproduced below, exactly as they are presented in [ROADMAP].
In addition, this profile also defines an "Intermediate CA", which
is a specialization of a Subordinate CA:
Root CA -- A CA that is directly trusted by an end entity; that is,
securely acquiring the value of a root CA public key requires some
out-of-band step(s). This term is not meant to imply that a root CA
is necessarily at the top of any hierarchy, simply that the CA in
question is trusted directly.
Top CA - A CA that is at the top of a PKI hierarchy.
Subordinate CA - A "subordinate CA" is one that is not a root CA for
the end entity in question. Often a subordinate CA will not be a root
CA for any entity but this is not mandatory.
Intermediate CA - A Subordinate CA that is located on a certification
path between the end entity and its Root CA.
"Top CA" denotes only the position of a given CA within a certification
hierarchy, but does not necessarily imply that the given CA is also a
"Root CA". A "Root CA" can be situated anywhere within a given
certification hierarchy. The "root-ness" comes from the trust relation.
Hence, a given CA can be a Root CA for some
entities but not for others. A given CA could simultaneously be both
a Subordinate CA for one end entity and a Root CA for another end entity.
>From the perspective of an IKE device, CAs that are located
in the PKI hierarchy above its own Root CA
(from a graph-theory viewpoint) play no role in the IKE
protocol. That is, as far as the end entity is
concerned, such CAs do not exist.
N.1 IKE Identification Certificate
An IKE device MUST store locally at least one IKE Identification
Certificate that binds a public key to each identity that the
device will place in the ID Payload field of the IKE
messages. The identities to which the public key is bound are the
union of the contents of the IKE Identification certificate's
"subject" field and "subjectAltName" extension.
For each IKE Identification Certificate that it will use in
conjunction with IKE, the IKE device MUST securely store the
associated private key locally.
AN IKE device MAY have multiple IKE Identification Certificates.
Methods used to generate an appropriate public-private key pair
are not constrained by this profile. Methods for initially
acquiring an IKE Identification Certificate from a CA are not
constrained by this profile.
N.2 Certificates of Root CA(s)
The IKE device MUST securely acquire and store a CA certificate
for each Root CA with which it has a trust relationship. The
methods used to obtain a valid Root CA certificate(s from the
intended Root CA are left as a local option for each IKE device,
and are not constrained by this profile.
The existence of a trust relationship with a given Root CA does
not require the IKE device to have in its possession an IKE
Identification Certificate that was issued by that Root CA.
N.3 Certification Paths
(NOTE: The definition below is based on Section 6.1 of RFC 2459.
However, the definition in this profile terminates the path at
a Root CA, while the definition and examples in RFC 2459, section 6.1
terminates it at what this profile calls a "Top CA".)
Each path between a given IKE device and its Root CA(s) may
include several Intermediate CAs, whose CA certificates comprise
the links on a "certification path" extending from the IKE device
to the Root CA(s).
More formally, a certification path between a given IKE device and
a Root CA consists of a set of "n-2" certificates, one for each
Intermediate CA between the IKE device and the Root CA under
consideration, where:
* the certificate of the Root CA is numbered "1"
* the certificates of Intermediate CAs, if any, are numbered
in the range from "2" to "n-1"
* the IKE Identification Certificate is numbered "n"
* for all x in {1, n-1}, the subject of certificate x is the
issuer of certificate x+1
For each Root CA that it recognizes, an IKE device MUST support
a certification paths containing up to seven (7) Intermediate CAs
(i.e. there can be up to 8 CA certificates, including that of the Root CA).
N.4 Certificates of Intermediate CAs
An IKE device MUST store locally a copy of each CA certificate
that is included in at least one of the certification path(s)
between itself and each of its own Root CA(s).
(NOTE: There may be multiple certification paths between a given
IKE device and a given Root CA. The requirement above does
not preclude an IKE device from storing locally all CA certificates
on all certification paths between itself and the Root CA.)
This profile does not constraint the methods that an IKE device can
use to obtain the certificates that comprise the certification path.
There is no requirement for an IKE device to store the CA
Certificates of any other device's Intermediate CAs. An
IKE device will learn the certification paths of the peer
with which it is engaged in an IKE negotiation by examining
the Certificate Payload fields that it receives from its peer,
as described in Sections XXX.
____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
Network Security Product Development (JEUA/502), RTP
Phone: Tie 8-444-4142 , External 919-254-4142
Fax: Tie 8-441-7288, External 919-543-7288
Follow-Ups: