[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "PKIX Profile for IKE"--Is it really a profile?
At 09:52 AM 10/25/99 -0400, kunzinge@us.ibm.com wrote:
>1. This draft's purpose is to provide a definitive profile
>for a specific way that IKE and PKIX will interoperate. We need
>a clear statement that defines what it means to comply with this
>draft, versus what it means to comply with the underlying IPSec
>and PKIX documents.
I fully agree with Charlie on this. Instead of a document that says "here
are some PKI issues", I think one that says "there are lots of PKI issues
and here's an exact profile that must be met to comply with this spec" is a
Very Good Thing.
>"This document defines a particular method of using IKE which is more
>restrictive than is necessary for compliance with RFC 2459, RFC 2408
>and RFC 2409. It defines a PKIX profile that is more restrictive
>than is necessary for compliance with RFC 2459.
I would say "different" instead of "more restrictive" because I don't agree
with most of the restrictions in the current draft.
>2. The current draft offers no definitive, unambiguous requirements
>for the profile. In general, it concentrates on high level statements
>of what MUST or MUST NOT be done, but it offers no detailed methods for
>accomplishing these tasks.
Here we disagree. I think the current document is quite definitive and
unambiguous in its requirements. I think that some of these requirements
will be removed, and other ones will be added.
> In reviewing this document, I find that
>there are only 6 ?MUSTs? (summarized below), and that none of them
>nail down any details. Without details, we have no stake in the
>ground on which to base interoperability claims.
Again, I disagree.
>The current "MUSTs" are:
>· MUST check revocation status of certificates on
> which an IKE implementation relies
In my mind, the details of how to do this should *only* be in the PKIX
document. I think it's a bad idea to duplicate the PKIX document,
particularly if we are going to subset and make up new terms.
>· MUST have a method for receiving up-to-date revocation information
Ditto.
>· MUST support a signing hierarchy
Ditto.
>· MUST delete SAs corresponding to certificates that have become invalid
I don't think we need any more detail on this given that how SAs are set up
is an implementation issue.
>· EKU MUST contain only object identifier iKEIntermedate
This is pretty clear.
>· MUST examine notAfter time in certificates
I can't imagine how this could be clearer.
>Note also that some of the important details about the operation of IKE
>are not addressed in this profile, even though in many cases the existing
>IKE specs leave the details open to interpretation. For example,
>there is no normative text to outline a profile-specific
>method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST
>payloads,
Quite correct and this is one of the areas that we *must* address.
> there is no normative text to describe certificate
>validation in IKE (e.g., what if an evaluating system does not trust
>its peer's root CA,
Then no validation happens, period. That's fully covered in PKIX.
> what are the normative rules for matching a
>certificate?s subject to IKE?s ID Payload fields,
That's a good question. Many companies have told me that they never intend
to match the subject to the IKE initiator. I find that scary, but it's what
many people want. I would prefer statements in this profile that say you
SHOULD (maybe MUST) match the subject, but that's open for debate.
> can a given IKE
>implementation recognize more than one root CA,
Of course; why not?
> what validation steps
>are needed for CA certificates of CAs located on a certification
>chain,
That's fully covered in PKIX and I think should not be duplicated here.
> can there be multiple certification chains between an end
>entity and its root CA(s)
Of course. PKIX doesn't restrict that at all.
To me, the current document's biggest hole is the lack of discussion of
Certificate and Certificate Request payloads, when they should appear, and
what they mean. I'd also like to see some things removed, which I'll
discuss in a different messsage.
--Paul Hoffman, Director
--VPN Consortium
References: