[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt
Greg Carter writes:
> 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.
Agreed.
>
> >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.
Why require that extendedKeyUsage be mandatory at all?
>
> 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.
Agreed. Plus, X.509 already defines upper bounds for the common DN fields,
for instance:
ub-common-name INTEGER ::= 64
ub-organization-name INTEGER ::= 64
Why not stick with these?
As for multi-byte character sets, ASN.1 SIZE constraints apply to the
number of actual characters, not the total number of bytes required
to represent the characters. So, if the upper-bound constraint is 64
characters and your character set requires 2 bytes per character, then
the maximum number of bytes is 128.
>
> >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?...
Agreed.
>
> Bye.
>
> Greg Carter
> Entrust Technologies - http://www.entrust.com
> http://www.ford-trucks.com/articles/buildup/dana60.html
brian
briank@network-alchemy.com
Follow-Ups:
References: