X.509 certificate subject format
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? I.e.: Does the order of elements matter? Does the order matter when fields are duplicate, i.e. are: subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? If they are not equal, does the first one have a special meaning? For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? 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? 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? Any help is greatly appreciated! Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] X.509 certificate subject format
Le 02/07/2012 10:34, Johannes Bauer a écrit : 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. I.e.: Does the order of elements matter? Does the order matter when fields are duplicate, i.e. are: The order of elements in a SEQUENCE matters. The order of elements in a SET doesn't matter (read X.690 to get DER rules). Comparison rules for AttributeAndValue elements follow X.520 recommendation (you have to canonicalize them before comparison). subject1= /CN=foo/CN=bar subject2= /CN=bar/CN=foo equal? Not equal. If they are not equal, does the first one have a special meaning? For example, assume a webserver with a duplicate common name field. Are both names valid as the server name then? 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 is not specified by X.509. Browsers tend to accept such a certificate for an accessed FQDN equal to either foo or bar. But you SHOULD place at most the first FQDN in a CN element in the subject, and other FQDN values in the subjectAlternativeName extension. 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 signature may be cryptographically valid, but the names don't match, so /OU=greatCA/O=myCA/CN=not is not the issuer of /CN=foo/CN=bar (at least not in what you described, /CN=foo/CN=bar may have another certificate). -- Erwann ABALEA - Pas de panique, ça sera pire. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: X.509 certificate subject format
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
