I guess it's worth pointing out that DN's in X.500 represent a pathname
from the root of a tree down to a leaf. I.e., conceptually there is a
top-down order just like in a hierarchical filesystem. Unfortunately the
X.500 standards never specified an order for displaying the components
in text lines. Most X.500 tools followed the filesystem convention,
using slashes as delimiters and listing the root first, descending left
to right. (e.g., /root/middle/leaf -> /c=us/o=my company/cn=some name)
A lot of confusion has arisen more recently because the LDAP designers
chose to ignore the established convention and specified their string
format to list DNs right to left, with the root on the right.
(leaf,middle,root -> cn=some name,o=my company,c=us)
The LDAP designers made a lot of stupid decisions....
Robert Eiglmaier wrote:
Thanks everybody for the replies.
I could convince the producer of the PKCS#7 to leave the attribute-order
unchanged.
So I don't need to modify X509_NAME_cmp().
Robert
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Sylvester
Sent: Montag, 23. Januar 2006 17:06
To: [email protected]
Subject: Re: Attribute order in name comparison
Some openssl does not necessarily display DNs in the same textual order
as other tools
or as other tools like it as input.
try
openssl x509 -in yourcert -text -noout -nameopt RFC2253
for example and another without the -nameopt parameter
It has happened several times that people create certificates that have
the order
of the attributes reversed. The only remedy was to remake the PKI since
we live with the historical accident of mixing a hierarchy together with
typed attributes in x.500, specifying the order means that one attribute
is a
subordinate
of the preceding one. I don't think that common name is a very good
candidate
for a top level attribute unless for CN=the universal authority or else
Or;
C=DE/O=Org/CN=Alice
and the other way around is not a clear description of the data. what
does openssl X509 .... show?
Peter
Lev Walkin wrote:
Robert Eiglmaier wrote:
Hi,
I have troubles verifying a PKCS#7 signedMessage because the order of
the DN attributes in the signerInfo is different from the order in
the certificate.
i. e.
The cert contains: C=DE/O=Org/CN=Alice
The signer info has: CN=Alice/O=Org/C=DE
I found that the function
int X509_NAME_cmp(const X509_NAME *a, const X509_NAME *b) will only
find the names matching if the attribute order is identical.
It wouldn't be a big deal to make X509_NAME_cmp() more tolerant, but
since appearantly nobody has had such a problem yet I'd like to know
if there is a specification somewhere that says something like "Thou
shalt not turn around the order of thy name attributes".
PKIX1 profile for X.509 certificates, as well as X.680 for ASN.1
SEQUENCE.
All I found was a statement, that SEQUENCE OF is ordered.
(distinguishedName is a SEQUENCE OF nameAttribute) But when I look at
an example Certificate I can't see by what it is being ordered here:
SEQUENCE
^^^^^^^^^^
this is a "SEQUENCE OF", not "SEQUENCE"
SET SEQUENCE OBJECT
:countryName 2.5.4.6
PRINTABLESTRING :DE
SET SEQUENCE OBJECT
:organizationName 2.5.4.10
PRINTABLESTRING :Company
SET SEQUENCE OBJECT
:commonName 2.5.4.3
PRINTABLESTRING :Demo CA
Can anyone bring some light into the darkness?
They are ordered sequence of unordered SET's of each element. The
order inside "SET OF" is not important, but there is exactly one
element in each SET OF. However, the order inside "SEQUENCE OF" is
important. And the order is the order of display, i.e. DE/Company/Demo
CA.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
