[Python-Dev] frozenset C API?
"Martin v. Löwis"
martin at v.loewis.de
Tue Sep 4 23:26:20 CEST 2007
> I'm working on issue 1583946. Nagle pointed out that each DN (the
> "subject" and "issuer" fields in a certificate) may have multiple
> values for the same attribute name, and I haven't been able to rule
> this out yet.
This is indeed common. In particular, DN= and OU= often occur multiple
times.
> X.509 DNs are sets of X.500 attributes, and X.500
> attributes may be either single-valued or multiple-valued.
Conceptually perhaps (although I doubt that). Practically, Name is
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
So it's a sequence of sets of key/value pairs. If you want to
have the same type twice, you have two options: either make
multiple RDNs, each single-valued, or make a single RDN,
with multiple kv-pairs.
IIUC, the intention of the multi-valued RDNs is that you have
an entity described by multiple attributes. For example,
relative to O=Foo, neither GN=Bill nor SN=Janssen might correctly
identify a person. So you would create O=Foo,GN=Bill+SN=Janssen.
That's allowed, but not really common - instead, people both
a) use CN as a unique identifier, and b) put separate
attributes for a single object into separate RDNs, as if
email=janssen at parc.com was a subnode in the DIT relative
to CN="Bill Janssen".
> I haven't
> found anything in the X.509 standard that prohibits multiple-valued
> attributes (yet -- I'm still looking), so I'm working on an
> alternative to using dicts to represent the set of attributes in the
> certificate that's returned from ssl.sslsocket.getpeercert().
Conceptually, it should be a list (order *is* relevant). It can
then be debated whether the RDN can be represented as a dictionary;
my understanding is that the intention of RDNs is that the AttributeType
is unique within an RDN (but I may be wrong).
Regards,
Martin
More information about the Python-Dev
mailing list