[Python-Dev] frozenset C API? (original) (raw)

"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