[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: