>From: raylau(_at_)EDU(_dot_)MIT (Raymond Lau)
>Subject: DNs, RDNs, AVAs, and DER coding
>Date: Tue, 15 Jun 93 22:08:46 EST
>
>From what mtr says, and I have no reason to doubt him as it
>matches my original understanding, all the types in the AVAs of
>a single RDN must be unique.
>
Of any number of values for an attribute type in an entry, only one may
be distinguished, and it is contained in the RDN (and thus DN) denoting
(uniquely) that entry. (Denotational quibbling difference, only, in
reality). For entry, substitute individual's right to a (Distinguished)
Name in PEM.
>This means the subject DN in the certificate below is bad but no
>one from RSA has confirmed it.
Now to the interesting bit:
It is a Name, and a valid one, though not a DN (by X.501, and
contradiction with above rule (X.501 7.4.3). It is legitimate in the
international environment to use such a Name value in either the
subject or issuer field of an X.509 Certificate. When verifying
the signature, verifiers need to map Names to DN, by any means
available.
I read RFC 1422 as profiling Names used in said fields, and
all X.400 P1, and X.511/521 similar fields, which would apply the PEM
certification profile, to be restricted to the associated DN. This
seems based on pragmatism.
Otherwise you need a mapping service in order to validate the
signature on any signed type containing a Name.
>subject DN = {C=US},{O=RSA Data Security, Inc.},
> {OU=Beta,OU=Commercial Certification Authority}
>
Perhaps their software suite maps this to the DN before performing
signature functions? So must all of ours, then. Do the NADF rules for
US jurisdictional namespace permit such (automatic) determination, in
the absence of on-line servers? I believe that this is the forum's
(highly useful) contention.