[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt
Hi,
I have a few comments on the draft, nothing shocking...
>From 1. Introduction, first paragraph:
"Note that many IPsec implementers are not completely happy with the PKIX
documents and procedures, but have agreed to use the PKIX protocols because
they are supported in other contexts and have a significant market share."
and last paragraph
"(It is noted that the fact that the two documents differ does not give
great confidence to the IPsec community or other users of the PKIX
protocols.)"
Both of these, whether or not true, are opinions and don't really do
anything to help implementers beside adding confusion. I would suggest they
be taken out for clarity.
>From section 3.1 The extendedKeyUsage field:
"In a certificate for an IPsec end entity, the extendedKeyUsage field
commonly called "EKU") MUST be present and MUST contain only the object
identifier iKEIntermediate
(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT
accept end-entity certificates that do not follow this rule."
Why must the certificate only have the one extended key usage? This is too
restrictive. I like the idea of only having one IPSec extended key usage
bit though. Could we stick with PKIX and say that if flagged critical then
it must only have one value. Therefore you could remove the "and MUST
contain only the object identifier iKEIntermediate..." since that would be
covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage
extensions.
In Section 3.2 The subjectAltName field, last paragraph:
"The subject field in IPsec certificates SHOULD be populated and non-null
(this is contrary to the PKIX certificate profile, which says that the
subject MUST NOT be populated if the identification is in the subjectAltName
field)"
This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name
that:
Further, if the only subject identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the subject
distinguished name MUST be empty (an empty sequence), and the subjectAltName
extension MUST be present. If the subject field contains an empty sequence,
the subjectAltName extension MUST be marked critical.
The important phase being "if the ONLY subject identity included in the
certificate is an alternate name form". It does not say "If the alternate
name form is used then NO subject distinguished name may be present." which
is how I read section 3.2. For clarity I would stick with the PKIX
definitions of how subject and alternate names are to be used and remove the
last paragraph.
If ONLY the alternate name is to be used then the subject should be left
empty as PKIX states. However in practice I do not know of any
implementations that only identify the 'device' by alternate name. For
administration purposes they will always have a subject name, however there
may exist a situation where someone would like to restrict to only using the
alternate name for identification and the only way to do this is with an
empty subject.
Also in the last paragraph of section 3.2:
"Distinguished names SHOULD be no more than four attribute/value pairs, each
of which SHOULD be no more than 128 characters in length (these restrictions
do not appear in the PKIX certificate profile)."
Again these are too restrictive. Names in the subject/issuer are dictated
by the customers directory setup (for those using one). In practice I have
seen longer names than 4 attribute/value pairs. Length... well I don't know
much about multi char character sets but I wouldn't want to limit anything
which would prevent IPSec certificates being used in foreign languages.
>From Appendix A:
"Regardless of the protocol used, a CA who gets an IKE system's enrollment
request that includes the subject and subjectAltName desired for the device
MUST include exactly the same subject and subjectAltName in the
certificate. If the CA does not want to issue a certificate with the same
subject and subjectAltName that was requested, the CA MUST NOT issue a
certificate with a different name and subjectAltName."
This places an unnecessary burden on the end entity to determine what
exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change
the DN that is in the request. If the device must have the exact DN then it
means a user somewhere has to type it in, very prone to failure. Also there
is no mention of how to verify the request at the CA. The device should
generate a hash of the der encoded request and make it available to the
devices administrator for verification at the CA. Otherwise the request is
accepted without verification. Also mention of how to obtain the CAs keys
in a secure way, similarly usually done with a hash of the CAs der encoded
certificate. May want to add this to the security section?...
Bye.
Greg Carter
Entrust Technologies - http://www.entrust.com
http://www.ford-trucks.com/articles/buildup/dana60.html
-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, October 19, 1999 6:52 AM
To: IETF-Announce
Cc: ipsec@lists.tislabs.com
Subject: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Protocol Working Group of the
IETF.
Title : A PKIX Profile for IKE
Author(s) : R. Thayer, C. Kunzinger, P. Hoffman
Filename : draft-ietf-ipsec-pki-req-03.txt
Pages : 28
Date : 18-Oct-99