[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:-ipsec-pki-req-03 - subject/subjectAltName
This is a comment on the subject distinguished name / subject
alternative name issue.
At 'the ANX-sponsored CA meeting in Needham Massachusetts'
a couple of years ago, we had a conversation about this.
It was claimed that certain environments will break if
you do not have a subject distinguished name. My original
proposal was that we invent a convention of
commonName = see-subject-alt-name for this case. Events in
the PKIX community overtook this. I think, therefore, that
the justification of this requirement has become deprecated.
I suggest we revert to following PKIX. I'll let Greg
and Paul flash their respective PKIX lawyer id badges at
each other and come up with some PKIX-compatible statement here,
but let's stop requiring subject distinguished name contents
be anything different from what PKIX wants.
On the subject of limits to the name, I am afraid I instigated
this. I thought there were not limits on this in PKIX. My
point was that we should put in SOME limit on name length.
If PKIX has something, I don't have a reason to use a different
number. This allows us to be compatible (or bug-compatible)
with PKIX on this point.
I don't think X.509 is relevant. It's an ugly old legacy
standard. PKIX's slavish devotion to it is quaint but
we should move beyond that. Quoting X.509 specs is not
relevant here, we're not building TP Class 4 over ISO IP...
>From: Brian Korver <briank@network-alchemy.com>
>Greg Carter writes:
>> 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.
Follow-Ups: