On 07/02/2012 10:34 AM, Johannes Bauer wrote:
Hi list,
I have a rather simple question regarding X.509 subjects that is not
entirely clear to me and for which I cannot find the appropriate
reference (pointers greatly appreciated). The trouble starts when trying
to compare two subjects of *different* certificates for equality and
becomes worse when certain fields are appearing more than once. To
clarify, by "equal" I mean 'should behave in exactly the same way by all
well-behaved implementations.
Let's start easy. Consider the following subjects:
subject1= /C=SE/O=FooBar/OU=BarFoo/CN=moo.koo.com
subject2= /C=SE/OU=BarFoo/CN=moo.koo.com/O=FooBar
Are these to be considered equal or not?
Not equal. beware, you are using a textual representation which is
probably the one of openssl. So C=SE is the first in the DN sequence.
Note that there is also the possibility to put several attribute into
one RDN.
I.e.: Does the order of
elements matter?
Yes.
Does the order matter when fields are duplicate, i.e. are:
subject1= /CN=foo/CN=bar
subject2= /CN=bar/CN=foo
equal?
No.
If they are not equal, does the first one have a special meaning?
X.509 and RFC 5280 defines a hierachical order of the relative
disdintiguised names that make up the sequence of the distinguished name.
For
example, assume a webserver with a duplicate common name field. Are both
names valid as the server name then?
No.
I.e. could I access a webserver
with the certificate subject as stated above by DNS "foo" *and* "bar" or
only by one of them?
This depends on the implemention of the client, and also whether
you have a subjectAltName extension. If there is a sibjectAltName
extension, the common name is (not supposed to be) used by a client.
One reason to ask for equality is that there maybe is a certificate X:
issuerX = /O=myCA/OU=greatCA/CN=not
subjectX= /CN=foo/CN=bar
and it has a valid signature by a CA with the following subject:
issuerX = /OU=greatCA/O=myCA/CN=not
Is the certificate signature then valid?
The certificate signature may be cryptographically valid,
but not the name chain in a path validation.
At least it shouldn't, there had been errors in some toolkits
in the past that treated the hierarchy as a heap of attributes.
/P
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
