[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments/Observations on IPSec/PKI Requirements
Charles,
>2. "IPsec-PKI" implies that an IPSec Identification Certificate should
>contain a non-empty "subject" field and also a "subjectAltName" field
>carrying an IP Address, a DNS Name, or an RFC822 Name. Our products will
>declare a match between the ID Payload field of the IKE messages whenever
>there is a match with either the certificate's "subject" field or with its
>"subjectAltName" field. Hence, we feel that the subjectAltName field must
>be marked as "non-critical" whenever the "subject" field is non-empty.
>However, we did not find a statement in IPSec-PKI to corroborate this
>approach.
It is solely up to the CA to determine whether the subjectAltName is
critical, or not. For example, if the CA is issuing a cert to represent a
DNS name, nut also includes a DN because of some requirement for LDAP
directory storage, it would not be unreasonable to mark the subjectAltName
critical.
>3. A related issue is the matter of matching certificate subjects and IKE
>ID Payloads. When one uses the public-key based IKE authentication
>methods, the contents of the ID Payload from IKE MUST match with at least
>one of named subjects of the IPSec Identification certificate. However, I
>couldn't find an explicit statement of this fact in "IPSec-PKI", nor does
>it define any explicit rules for determining a mathc (or mismatch). We
>will try to offer some draft text for "IPSec-PKI" section 3.5 in a separate
>posting to address this and other issues within the next few days.
Matching should be controlled by the rules for the name type in question.
IKE supports DNs, DNS names, Ip addresses, and RFC822 names. Each has
different matching rules, e.g., DNS and RFC822 names are case insensitive,
whereas DNS have an elaborate set of matching rules inherited from the
directory.
>4. Since an entity can associate the same public key with several different
>identities, RFC 2459 allows "subjectAltName" field to name multiple
>identities within a given certificate (see RFC 2459, section 4.3.1.7 for
>example). Note also that the "Roadmap" in section 5.1.1.2 expressly permits
>the "subjectAltName" field to carry multiple name forms, and also allows
>multiple instances of any given name form. Section 4.1.2 if IPSec-PKI
>appears to permit multiple name forms within the subjectAltName field, but
>appears to denigrate the appearance of multiple instances of a given name
>form ("This field SHOULD contain at most one of each of these values...").
>Why the strong recommendation against using multiple instances of the same
>name form? For example, a given person may have multiple e-mail addresses,
>and it would be convenient to be able to include all of them within the
>"subjectAltName" field of a given certificate.
I always recommend use of the NameConstraints extension with certs, to
minimize the damage done by a CA error, or by a malicious CA. Although one
c an use this extension with a cert that contains multiple names and name
forms, the processing becomes more complex as a result. Thus, I would
recommend against trying to put too many names in the same cert. For
example, if I have a BBN e-mail address, it is fine for a BBN CA to issue a
cert for that, but it would be inappropriate for the BBN CA to put in my
Erol's e-mail address too, since that CA is NOT authoritative for e-mail
addresses in the Erol's domain. Thus one could have a simgle cert with
multiple e-mail addresses, but it would be a bad idea unless these
addresses were all in the same domain.
>4. We do not see value in the ExtendedKeyUsage extension outlined in
>IPSec-PKI. Imposing a granularity at the level of a end node or an
>intermediate node is not realistic. A given Security Gateway, for example,
>may play the role of intermediate node when it is acting as proxy for
>systems located behind it, but may also play the role of end node when it
>is exchanging information on a peer basis with another Gateway box. We do
>not wish to have to obtain multiple certificates to accommodate this
>situation. If the IPSec working group elects to retain this extension in
>IPSec Identification certificates, then as a minimum it should be marked as
>"non-critical".
Why do you worry about obtaining multiple certs for the example you cited?
Increasiningly people don't vharge on a per-cert basis (or don't charge
much). I'm not arguing that this is very important, but I didn't see the
example you cited as persuasive as a reason for not using EKU.
>5. "IPSec-PKI" does not discuss the use of "wildcard" name forms in the
>subjectAltName field of the certificate (section 4.1.2 discusses only
>non-wildcard name forms), but the "Roadmap" states that after due
>deliberation, the PKIX WG will permit the use of wildcards in name forms
>(see "Roadmap" section 5.1.5). We are uncertain about the value of
>allowing wildcard name forms in IPSec Identification certificates, and
>would appreciate feedback from working group members on this topic.
The Roadmap is wrong in this case. If you look at the RFC you will see NO
support for wildcard name forms.
>6. RFC2459 describes a critical extension for CA
>certificates("basicConstraints", section 4.2.1.10). This field indicates
>if the subject is (or is not) a CA, and it also places a limit on the
>number of subordinate CA that can be in a certification chain between
>itself and the IPSec device. Should "IPSec-PKI" require that this field be
>checked during certificate validation--that is, should we reject a peer's
>IPSec Identification certificate if its certification path is too long?
Compliant processing relative to RFC 2459 requires such checking. If you
want to be able to say that an IPsec device complies with this RFC (as a
certificate consumer or relying party) as part of your marketing
literature, then you must perform all the checks called for, if you receive
a cert with such extensions. Since this is an extension that MUST appear
in a CA cert, and MUST NOT appear in an end entity cert, you really ought
to check that the cert paths you process
conform to these requirements.
Steve
References: