Wrong DNs

[Michael Bell]

Hi,

we found today a big problem with the DNs which OpenSSL displays because
our application (OpenCA) produce DNs which are conform to the
directorystandards but OpenSSL interprets them in the opposite order.
What does this mean?

Here an example:

The root of our directory is the following: o=HU, c=de

The organizational unit for the PKI is Test-CA. So the next DN in the
directory must be:
ou=Test-CA, o=HU, c=de

A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".

It is no problem to produce this DN with OpenSSL but then we were a
little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
(openssl-*/cerst/). All these trustcenters use LDAP-servers but these
DNs can never be stored in a directoryserver!

So it looks like OpenSSL displays the different parts of a DN in the
wrong order. Did I make a misinterpretation? If this is a bug then I
have the next question, can you fix this in the 0.9.7-tree?

It is possible to protect the old index.txt etc. by adding an option
-x500 or something like this to get a DN which can be inserted in a
directoryserver. The problem is that OpenSSL interprets a correct DN
with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
"wrong" certificate).

I know no optimal solution except of adding such an option to every
related command or add an option like -oldstyledn to "openssl x509" and
"openssl ca" but before starting discussing solutions I will wait for an
answer (bug or misinterpretation).

Best Regards, Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Vadim Fedukovich]

On Mon, 15 Apr 2002, Michael Bell wrote:

> Hi,
>
> we found today a big problem with the DNs which OpenSSL displays because
> our application (OpenCA) produce DNs which are conform to the
> directorystandards but OpenSSL interprets them in the opposite order.
> What does this mean?
>
> Here an example:
>
> The root of our directory is the following: o=HU, c=de
>
> The organizational unit for the PKI is Test-CA. So the next DN in the
> directory must be:
> ou=Test-CA, o=HU, c=de
>
> A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
>
> It is no problem to produce this DN with OpenSSL but then we were a
> little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> DNs can never be stored in a directoryserver!
>
> So it looks like OpenSSL displays the different parts of a DN in the
> wrong order. Did I make a misinterpretation? If this is a bug then I
> have the next question, can you fix this in the 0.9.7-tree?
>
> It is possible to protect the old index.txt etc. by adding an option
> -x500 or something like this to get a DN which can be inserted in a
> directoryserver. The problem is that OpenSSL interprets a correct DN
> with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> "wrong" certificate).
>
> I know no optimal solution except of adding such an option to every
> related command or add an option like -oldstyledn to "openssl x509" and
> "openssl ca" but before starting discussing solutions I will wait for an
> answer (bug or misinterpretation).
>
> Best Regards, Michael

Michael,

LDAP-style DNs are never of concern while signature verification.
Please note LDAP encode names in a different, "lightweight" manner.
One may want to use other (non-openssl) tools to manage that encoding
(LDAP trees).

regards,
Vadim


p.s One may also add standard bodies did some damage by introducing
complex and confusing name handling. This effectively keeps developers
out of real crypto, the source of power. Yes, some fair-tales
suggest the need to cast real true name of a creature sometimes :)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Michael Bell]

Vadim Fedukovich schrieb:
> 
> On Mon, 15 Apr 2002, Michael Bell wrote:
> 
> > Hi,
> >
> > we found today a big problem with the DNs which OpenSSL displays because
> > our application (OpenCA) produce DNs which are conform to the
> > directorystandards but OpenSSL interprets them in the opposite order.
> > What does this mean?
> >
> > Here an example:
> >
> > The root of our directory is the following: o=HU, c=de
> >
> > The organizational unit for the PKI is Test-CA. So the next DN in the
> > directory must be:
> > ou=Test-CA, o=HU, c=de
> >
> > A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
> >
> > It is no problem to produce this DN with OpenSSL but then we were a
> > little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> > with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> > (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> > DNs can never be stored in a directoryserver!
> >
> > So it looks like OpenSSL displays the different parts of a DN in the
> > wrong order. Did I make a misinterpretation? If this is a bug then I
> > have the next question, can you fix this in the 0.9.7-tree?
> >
> > It is possible to protect the old index.txt etc. by adding an option
> > -x500 or something like this to get a DN which can be inserted in a
> > directoryserver. The problem is that OpenSSL interprets a correct DN
> > with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> > "wrong" certificate).
> >
> > I know no optimal solution except of adding such an option to every
> > related command or add an option like -oldstyledn to "openssl x509" and
> > "openssl ca" but before starting discussing solutions I will wait for an
> > answer (bug or misinterpretation).
> >
> > Best Regards, Michael
> 
> Michael,
> 
> LDAP-style DNs are never of concern while signature verification.
> Please note LDAP encode names in a different, "lightweight" manner.
> One may want to use other (non-openssl) tools to manage that encoding
> (LDAP trees).

What do you want to say with this answer? The problem has nothing to do
with signature verification. If you use "openssl x509" or any other
openssl command then you will see a DN. The question is, why is the
order (in which the DN is displayed) different from the one used for
LDAP. Use X.500 the opposite order of LDAP?

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Michael Bell]

Michael Bell schrieb:
> 
> Vadim Fedukovich schrieb:
> >
> > On Mon, 15 Apr 2002, Michael Bell wrote:
> >
> > > Hi,
> > >
> > > we found today a big problem with the DNs which OpenSSL displays because
> > > our application (OpenCA) produce DNs which are conform to the
> > > directorystandards but OpenSSL interprets them in the opposite order.
> > > What does this mean?
> > >
> > > Here an example:
> > >
> > > The root of our directory is the following: o=HU, c=de
> > >
> > > The organizational unit for the PKI is Test-CA. So the next DN in the
> > > directory must be:
> > > ou=Test-CA, o=HU, c=de
> > >
> > > A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
> > >
> > > It is no problem to produce this DN with OpenSSL but then we were a
> > > little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> > > with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> > > (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> > > DNs can never be stored in a directoryserver!
> > >
> > > So it looks like OpenSSL displays the different parts of a DN in the
> > > wrong order. Did I make a misinterpretation? If this is a bug then I
> > > have the next question, can you fix this in the 0.9.7-tree?
> > >
> > > It is possible to protect the old index.txt etc. by adding an option
> > > -x500 or something like this to get a DN which can be inserted in a
> > > directoryserver. The problem is that OpenSSL interprets a correct DN
> > > with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> > > "wrong" certificate).
> > >
> > > I know no optimal solution except of adding such an option to every
> > > related command or add an option like -oldstyledn to "openssl x509" and
> > > "openssl ca" but before starting discussing solutions I will wait for an
> > > answer (bug or misinterpretation).
> > >
> > > Best Regards, Michael
> >
> > Michael,
> >
> > LDAP-style DNs are never of concern while signature verification.
> > Please note LDAP encode names in a different, "lightweight" manner.
> > One may want to use other (non-openssl) tools to manage that encoding
> > (LDAP trees).

see RFC 2253 for decoding of ASN.1 distinguished names to UTF-8 Strings.

Best Regards,

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Wrong DNs

[Howard Chu]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell

> Vadim Fedukovich schrieb:
> >
> > On Mon, 15 Apr 2002, Michael Bell wrote:
> >
> > > Hi,
> > >
> > > we found today a big problem with the DNs which OpenSSL
> displays because
> > > our application (OpenCA) produce DNs which are conform to the
> > > directorystandards but OpenSSL interprets them in the opposite order.
> > > What does this mean?
> > >
> > > Here an example:
> > >
> > > The root of our directory is the following: o=HU, c=de
> > >
> > > The organizational unit for the PKI is Test-CA. So the next DN in the
> > > directory must be:
> > > ou=Test-CA, o=HU, c=de
> > >
> > > A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
> > >
> > > It is no problem to produce this DN with OpenSSL but then we were a
> > > little bit shocked when we see the DNs of Thawte, VeriSign,
> Entrust etc.
> > > with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> > > (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> > > DNs can never be stored in a directoryserver!
> > >
> > > So it looks like OpenSSL displays the different parts of a DN in the
> > > wrong order. Did I make a misinterpretation? If this is a bug then I
> > > have the next question, can you fix this in the 0.9.7-tree?
> > >
> > > It is possible to protect the old index.txt etc. by adding an option
> > > -x500 or something like this to get a DN which can be inserted in a
> > > directoryserver. The problem is that OpenSSL interprets a correct DN
> > > with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> > > "wrong" certificate).
> > >
> > > I know no optimal solution except of adding such an option to every
> > > related command or add an option like -oldstyledn to "openssl
> x509" and
> > > "openssl ca" but before starting discussing solutions I will
> wait for an
> > > answer (bug or misinterpretation).
> > >
> > > Best Regards, Michael
> >
> > Michael,
> >
> > LDAP-style DNs are never of concern while signature verification.
> > Please note LDAP encode names in a different, "lightweight" manner.
> > One may want to use other (non-openssl) tools to manage that encoding
> > (LDAP trees).
>
> What do you want to say with this answer? The problem has nothing to do
> with signature verification. If you use "openssl x509" or any other
> openssl command then you will see a DN. The question is, why is the
> order (in which the DN is displayed) different from the one used for
> LDAP. Use X.500 the opposite order of LDAP?
>
> Michael

There is no bug, unless you consider LDAP itself a bug. Yes, LDAP uses the
opposite order from X.500. OpenSSL is using the correct (X.500) order.

Just as an aside, OpenLDAP 2.1 supports X.500 DNs.

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Lutz Jaenicke]

On Mon, Apr 15, 2002 at 08:57:00PM +0200, Michael Bell wrote:
> Hi,
> 
> we found today a big problem with the DNs which OpenSSL displays because
> our application (OpenCA) produce DNs which are conform to the
> directorystandards but OpenSSL interprets them in the opposite order.
> What does this mean?
> 
> Here an example:
> 
> The root of our directory is the following: o=HU, c=de
> 
> The organizational unit for the PKI is Test-CA. So the next DN in the
> directory must be:
> ou=Test-CA, o=HU, c=de
> 
> A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
> 
> It is no problem to produce this DN with OpenSSL but then we were a
> little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> DNs can never be stored in a directoryserver!
> 
> So it looks like OpenSSL displays the different parts of a DN in the
> wrong order. Did I make a misinterpretation? If this is a bug then I
> have the next question, can you fix this in the 0.9.7-tree?
> 
> It is possible to protect the old index.txt etc. by adding an option
> -x500 or something like this to get a DN which can be inserted in a
> directoryserver. The problem is that OpenSSL interprets a correct DN
> with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> "wrong" certificate).
> 
> I know no optimal solution except of adding such an option to every
> related command or add an option like -oldstyledn to "openssl x509" and
> "openssl ca" but before starting discussing solutions I will wait for an
> answer (bug or misinterpretation).

Hmm. As far as I could see with "openssl x509" and "openssl asn1parse",
certificates are printed in the order of the data inside the certificate.
Whatever this means :-)

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Michael Bell]

Howard Chu schrieb:
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell
> 

> > What do you want to say with this answer? The problem has nothing to do
> > with signature verification. If you use "openssl x509" or any other
> > openssl command then you will see a DN. The question is, why is the
> > order (in which the DN is displayed) different from the one used for
> > LDAP. Use X.500 the opposite order of LDAP?
> 
> There is no bug, unless you consider LDAP itself a bug. Yes, LDAP uses the
> opposite order from X.500. OpenSSL is using the correct (X.500) order.

Until now I thought X.500 uses ASN.1 encoded DNs only and LDAP supports
UTF-8 too. So there is a definition in X.500 how to transform ASN.1
encoded DNs to UTF-8?

Best Regards,

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Mon, 15 Apr 2002 20:57:00 +0200, 
Michael Bell <[EMAIL PROTECTED]> said:

michael.bell> we found today a big problem with the DNs which OpenSSL
michael.bell> displays because our application (OpenCA) produce DNs
michael.bell> which are conform to the directorystandards but OpenSSL
michael.bell> interprets them in the opposite order. 
michael.bell> What does this mean?

If I remember correctly, X.500 subjects are usually ordered as the
inverse of the directory standards you refer to.  This means that
rather than O=HU, C=DE, the order would be C=DE, O=HU.

However, with the OpenSSL application ('openssl'), which I assume is
what you've been using, the order of the RDNs entirely depends on the
order of the keys in the policy section from the configuration file.
In the example openssl.cnf, the order is contryName first, followed by
stateOrProvinceName, and so on.  I'm sure that if you create a
different policy section where things are reordered the waty you want
them, you'll get the desired result.

All this, of course, said out of memory.  I haven't tested anything.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Wrong DNs

[Howard Chu]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell

> Howard Chu schrieb:
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bell
> >
>
> > > What do you want to say with this answer? The problem has
> nothing to do
> > > with signature verification. If you use "openssl x509" or any other
> > > openssl command then you will see a DN. The question is, why is the
> > > order (in which the DN is displayed) different from the one used for
> > > LDAP. Use X.500 the opposite order of LDAP?
> >
> > There is no bug, unless you consider LDAP itself a bug. Yes,
> LDAP uses the
> > opposite order from X.500. OpenSSL is using the correct (X.500) order.
>
> Until now I thought X.500 uses ASN.1 encoded DNs only and LDAP supports
> UTF-8 too. So there is a definition in X.500 how to transform ASN.1
> encoded DNs to UTF-8?

The question makes no sense. ASN.1 is a specification for a transmission
format, but it doesn't make detailed specifications of the semantics of the
transmitted data. Both X.500 and LDAP use ASN.1 for their over-the-wire data
transfers.

UTF-8 is also simply a specification for the formatting of character-data,
it says nothing about the semantics of strings of characters.

At its core, LDAP is simply a different front-end for the X.500 information
model. A DN is a name that uniquely identifies an object in the X.500 name
space. Practically speaking, a DN is a DN. In pure X.500, DNs are specified
to be big-endian, most-significant component listed first. An X.500
directory path follows the same convention as a Unix filesystem path in this
regard. In LDAP, the convention is to display the DNs in the opposite order,
but the semantic meaning of the DN is unchanged. The X.500 representation
/c=us/o=foo/ou=people/cn=joe
specifies the exact same object as the LDAP DN
cn=joe,ou=people,o=foo,c=us

The difference is purely a matter of presentation.

To answer your question "is there a definition of how to transform X.500 DNs
to LDAP representation?" the answer is yes, it's RFC 2253.

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Wrong DNs

[Howard Chu]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS
> Whacker

> In message <[EMAIL PROTECTED]> on Mon, 15 Apr
> 2002 20:57:00 +0200, Michael Bell <[EMAIL PROTECTED]> said:
>
> michael.bell> we found today a big problem with the DNs which OpenSSL
> michael.bell> displays because our application (OpenCA) produce DNs
> michael.bell> which are conform to the directorystandards but OpenSSL
> michael.bell> interprets them in the opposite order.
> michael.bell> What does this mean?
>
> If I remember correctly, X.500 subjects are usually ordered as the
> inverse of the directory standards you refer to.  This means that
> rather than O=HU, C=DE, the order would be C=DE, O=HU.
>
> However, with the OpenSSL application ('openssl'), which I assume is
> what you've been using, the order of the RDNs entirely depends on the
> order of the keys in the policy section from the configuration file.
> In the example openssl.cnf, the order is contryName first, followed by
> stateOrProvinceName, and so on.  I'm sure that if you create a
> different policy section where things are reordered the waty you want
> them, you'll get the desired result.
>
> All this, of course, said out of memory.  I haven't tested anything.

All of the above is true, but I believe it would be a bad idea to go
changing
the order of everything. Certificates are specified in X.509 and are
properly
a part of the X.500 family, and the X.500 DN syntax is clearly specified.
Any software that claims to support X.509 certificates must operate using
X.500 syntax. The LDAP DN specification is backwards, and a cert with
"backwards" DNs could only be considered to be broken, and certainly will
not be interoperable with the vast majority of already deployed PKI.

Of course, nothing says you can't add a function to the OpenSSL library to
extract certificate DNs in LDAP format instead of X.500 format, it's just a
matter of traversing the Name in the opposite order when parsing/printing it
out. I believe this feature already was added in OpenSSL 0.9.6, so this
whole discussion has been about a non-problem...

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Vadim Fedukovich]

On Tue, 16 Apr 2002, Michael Bell wrote:

> Vadim Fedukovich schrieb:
> >
> > On Mon, 15 Apr 2002, Michael Bell wrote:
> >
> > > Hi,
> > >
> > > we found today a big problem with the DNs which OpenSSL displays because
> > > our application (OpenCA) produce DNs which are conform to the
> > > directorystandards but OpenSSL interprets them in the opposite order.
> > > What does this mean?
> > >
> > > Here an example:
> > >
> > > The root of our directory is the following: o=HU, c=de
> > >
> > > The organizational unit for the PKI is Test-CA. So the next DN in the
> > > directory must be:
> > > ou=Test-CA, o=HU, c=de
> > >
> > > A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
> > >
> > > It is no problem to produce this DN with OpenSSL but then we were a
> > > little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> > > with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> > > (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> > > DNs can never be stored in a directoryserver!
> > >
> > > So it looks like OpenSSL displays the different parts of a DN in the
> > > wrong order. Did I make a misinterpretation? If this is a bug then I
> > > have the next question, can you fix this in the 0.9.7-tree?
> > >
> > > It is possible to protect the old index.txt etc. by adding an option
> > > -x500 or something like this to get a DN which can be inserted in a
> > > directoryserver. The problem is that OpenSSL interprets a correct DN
> > > with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> > > "wrong" certificate).
> > >
> > > I know no optimal solution except of adding such an option to every
> > > related command or add an option like -oldstyledn to "openssl x509" and
> > > "openssl ca" but before starting discussing solutions I will wait for an
> > > answer (bug or misinterpretation).
> > >
> > > Best Regards, Michael
> >
> > Michael,
> >
> > LDAP-style DNs are never of concern while signature verification.
> > Please note LDAP encode names in a different, "lightweight" manner.
> > One may want to use other (non-openssl) tools to manage that encoding
> > (LDAP trees).
>
> What do you want to say with this answer? The problem has nothing to do
> with signature verification. If you use "openssl x509" or any other
> openssl command then you will see a DN. The question is, why is the
> order (in which the DN is displayed) different from the one used for
> LDAP. Use X.500 the opposite order of LDAP?

LDAP and X.509 handle names in a quite different ways, with component
order to be the most visible part. It could be safe to let LDAP API
to handle that encoding.

regards,
Vadim

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Robert Joop]

On 02-04-16 11:02:58 CEST, Howard Chu wrote:
> the order of everything. Certificates are specified in X.509 and are
> properly
> a part of the X.500 family, and the X.500 DN syntax is clearly specified.

the syntax is clearly specified, but the only thing that i could find
about the RDN order is implicit from an example DN in X.501 that starts
with "{ C=US, ".
where does it explicitly say that DNs should start with the most
significant part at the left end and continue to the least significant?

> Any software that claims to support X.509 certificates must operate using
> X.500 syntax. The LDAP DN specification is backwards, and a cert with
> "backwards" DNs could only be considered to be broken, and certainly will
> not be interoperable with the vast majority of already deployed PKI.

is the order part of X.500 syntax (isn't it semantics?) or is it just
a general convention?

and why is LDAP reversed?
because LDAP is an internet standard and the internet's DNS domain names
are ordered that way?

in peter gutmann's X.509 style guide i see both sort orders mentioned...

so, how does one best handle this mess?
expect X.509 DNs to be big endian and reverse them to be little endian
for use with LDAP?

i'm assuming here that in both cases the display order is the same as
the ASN.1 SEQUENCE order.
is that assumption correct?
(in other words: do the ASN.1 representations (DER) for X.509 and LDAP
DNs differ or just their human readable presentation?)

rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Robert Joop]

On 02-04-16 10:51:31 CEST, Howard Chu wrote:
> At its core, LDAP is simply a different front-end for the X.500 information
> model. A DN is a name that uniquely identifies an object in the X.500 name
> space. Practically speaking, a DN is a DN. In pure X.500, DNs are specified
> to be big-endian, most-significant component listed first. An X.500
> directory path follows the same convention as a Unix filesystem path in this
> regard. In LDAP, the convention is to display the DNs in the opposite order,
> but the semantic meaning of the DN is unchanged. The X.500 representation
>   /c=us/o=foo/ou=people/cn=joe
> specifies the exact same object as the LDAP DN
>   cn=joe,ou=people,o=foo,c=us

in other words, you mean that the X.500 presentation c=us,cn=John Doe
and the LDAP presentation cn=John Doe,c=us have the exact same DER byte
stream encoding?

can you or anyone else prove this? :-)

> To answer your question "is there a definition of how to transform X.500 DNs
> to LDAP representation?" the answer is yes, it's RFC 2253.

you mean (RFC 2253, 2.1)

   [...] the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to 2.2),
   starting with the last element of the sequence and moving backwards
   toward the first.

with "backwards" being the key word?

seems to make sense, i wasn't aware of that before.
thanks.

rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 16 Apr 2002 15:54:46 
+0200, [EMAIL PROTECTED] (Robert Joop) said:

joop> is the order part of X.500 syntax (isn't it semantics?) or is it just
joop> a general convention?

I've perceived it as a general convention.

BTW, thinking about it, I'm not sure why this discussion acme up at
all.  Certificates are often stored as attributes of a record (eh,
terminology isn't a strength of mine, so if "record" isn't the proper
term, please pardon me), at least in the directories that I've viewed,
and the LDAP DN isn't necesserely the same (obviously, it's at least
inversed :-)).

So I wonder, what exactly is the problem here?  Do the OpenCA folks
want the LDAP DN and the X.509 DN in their certificates to have an
exact match?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Harald Koch]

> In LDAP, the convention is to display the DNs in the opposite order,
> but the semantic meaning of the DN is unchanged. The X.500 representation
>   /c=us/o=foo/ou=people/cn=joe
> specifies the exact same object as the LDAP DN
>   cn=joe,ou=people,o=foo,c=us
> 
> The difference is purely a matter of presentation.

And I believe that thee root of the confusion is syntax.

X.500 uses the '/' convention, while RFC 2253 uses the ',' convention.

OpenSSL 0.9.7-dev (and possibly other versions) print the DN using ','
notation but in the wrong order in the case where you dump the entire
certificate, eg.

openssl x509 -in foo.pem -noout -text
gives
Subject: C=CA, ST=ON, O=cfrq.net, OU=SSL Client, CN=Harald Koch
 

If you say:

openssl x509 -in ~/lib/CA/client-cert.pem -noout -subject
you get
subject= /C=CA/ST=ON/O=cfrq.net/OU=SSL Client/CN=Harald Koch

and if you say:
openssl x509 -in ~/lib/CA/client-cert.pem -noout -subject -nameopt rfc2253
you get:
subject= CN=Harald Koch,OU=SSL Client,O=cfrq.net,ST=ON,C=CA

both of which are correct.
-- 
Harald Koch <[EMAIL PROTECTED]>

"It takes a child to raze a village."
-Michael T. Fry
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 16 Apr 2002 23:58:28 
+0200, [EMAIL PROTECTED] (Robert Joop) said:

joop> it's the different presentations of a DN that are inverses.

I just looked again at the relevant section of RFC 2253 with a much
more awake brain.  Seems like you are correct.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 16 Apr 2002 11:29:00 -0400, 
Harald Koch <[EMAIL PROTECTED]> said:

chk> X.500 uses the '/' convention, while RFC 2253 uses the ',' convention.

About X.500, that seems to be incorrect.  I just looked through X.501
(which describes the directory models), and the few examples that
exist in chapter 9 (Names) and Annex H (Name Design Criteria) indicate
that the RDNs should be separated by ',' rather than prefixed with
'/'.

IIRC, the '/' convention is from X.400 addresses.  Why it's used in
OpenSSL (as a renmant from SSLeay) is beyond me.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Wrong DNs

[Howard Chu]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Joop

> On 02-04-16 10:51:31 CEST, Howard Chu wrote:
> >In LDAP, the convention is to display the DNs in the
> opposite order,
> > but the semantic meaning of the DN is unchanged. The X.500
> representation
> > /c=us/o=foo/ou=people/cn=joe
> > specifies the exact same object as the LDAP DN
> > cn=joe,ou=people,o=foo,c=us

> in other words, you mean that the X.500 presentation c=us,cn=John Doe
> and the LDAP presentation cn=John Doe,c=us have the exact same DER byte
> stream encoding?

> can you or anyone else prove this? :-)

Remember that LDAP was originally only a front-end for ISODE, an actual
X.500 directory. The "ldapd" spoke LDAP on one side and DAP on the other
side. While the LDAP packets are BER-encoded, the DNs in those packets were
in string format. In X.500 a DN is encoded as a sequence of OIDs and values,
not as a sequence of strings. So of course, the answer to the question of
DER-encoding is "no!" But it was the job of the ldapd to translate between
forms.

> > To answer your question "is there a definition of how to
> transform X.500 DNs
> > to LDAP representation?" the answer is yes, it's RFC 2253.
>
> you mean (RFC 2253, 2.1)
>
>[...] the output consists of the string encodings of each
>RelativeDistinguishedName in the RDNSequence (according to 2.2),
>starting with the last element of the sequence and moving backwards
>toward the first.
>
> with "backwards" being the key word?
>
> seems to make sense, i wasn't aware of that before.
> thanks.

Yes, exactly. And for the X.500 definitions, I refer you to X.501 section
9.2 "Names in General" :
Each initial sub-sequence of the name of an object is also the name
an object. The sequence of objects so identified, starting with the
root and ending with the object being named, is such that each is the
immediate superior of that which follows it in the sequence.

And X.501 section 9.7 "Distinguished Names":
The distinguished name of a given object is defined as that name which
consists of the sequence of the RDNs of the entry which represents the
object and those of all of its superior entries (in descending order).

  -- Howard Chu
  Chief Architect, Symas Corp.   Director, Highland Sun
  http://www.symas.com   http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Oscar Jacobsson]

Well...

I think it's more a case of OpenSSL and LDAP using *different*
mechanisms for string encoding. LDAP reverses the RDN sequence (making
it conform to RFC 2253), while OpenSSL (and this goes back to SSLeay)
does not.

I don't think you could really claim that there was an "X.500 order" at
all, rendering the correctness issue moot, since X.500 (AFAIK) never
uses string representations of DNs.

The only standardized mechanism for string encoding DNs I am aware of is
that of RFC 2253, or LDAP. OpenSSL currently does not conform to it.

//oscar

Howard Chu wrote:
> There is no bug, unless you consider LDAP itself a bug. Yes, LDAP uses the
> opposite order from X.500. OpenSSL is using the correct (X.500) order.
> 
> Just as an aside, OpenLDAP 2.1 supports X.500 DNs.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Robert Joop]

On 02-04-16 16:49:25 CEST, Richard Levitte - VMS Whacker wrote:
> BTW, thinking about it, I'm not sure why this discussion acme up at
> all.  Certificates are often stored as attributes of a record (eh,
> terminology isn't a strength of mine, so if "record" isn't the proper
> term, please pardon me), at least in the directories that I've viewed,
> and the LDAP DN isn't necesserely the same (obviously, it's at least
> inversed :-)).

no, it is not. :-)
it's the different presentations of a DN that are inverses.

> So I wonder, what exactly is the problem here?  Do the OpenCA folks

the exact problem is that the openca-developers were confused.
and most people here didn't know much better either? :-)
but howard chu's comments made me look for a proof that both the X.500
presentation and the LDAP presentation--despite their opposite order--
describe the same DER presentation, and i think i found it in RFC 2253
2.1.

now we (openca developers) can write code to handle this mess.

rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Wrong DNs

[Michael Bell]

Harald Koch schrieb:
> 
> > In LDAP, the convention is to display the DNs in the opposite order,
> > but the semantic meaning of the DN is unchanged. The X.500 representation
> >   /c=us/o=foo/ou=people/cn=joe
> > specifies the exact same object as the LDAP DN
> >   cn=joe,ou=people,o=foo,c=us
> >
> > The difference is purely a matter of presentation.
> 
> And I believe that thee root of the confusion is syntax.
> 
> X.500 uses the '/' convention, while RFC 2253 uses the ',' convention.
> 
> OpenSSL 0.9.7-dev (and possibly other versions) print the DN using ','
> notation but in the wrong order in the case where you dump the entire
> certificate, eg.
> 
> openssl x509 -in foo.pem -noout -text
> gives
> Subject: C=CA, ST=ON, O=cfrq.net, OU=SSL Client, CN=Harald Koch
> 
> 
> If you say:
> 
> openssl x509 -in ~/lib/CA/client-cert.pem -noout -subject
> you get
> subject= /C=CA/ST=ON/O=cfrq.net/OU=SSL Client/CN=Harald Koch
> 
> and if you say:
> openssl x509 -in ~/lib/CA/client-cert.pem -noout -subject -nameopt rfc2253
> you get:
> subject= CN=Harald Koch,OU=SSL Client,O=cfrq.net,ST=ON,C=CA

Thanks for this hint. This really helps.

The only bad detail is now "openssl -subj" which use a DN with ","
inside but the order is the one from X.500.

Best Regards,

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [Openca-Users] Wrong DNs

[Robert Hannemann]

Michael Bell schrieb:

> Hi,
>
> we found today a big problem with the DNs which OpenSSL displays because
> our application (OpenCA) produce DNs which are conform to the
> directorystandards but OpenSSL interprets them in the opposite order.
> What does this mean?
>
> Here an example:
>
> The root of our directory is the following: o=HU, c=de
>
> The organizational unit for the PKI is Test-CA. So the next DN in the
> directory must be:
> ou=Test-CA, o=HU, c=de
>
> A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de".
>
> It is no problem to produce this DN with OpenSSL but then we were a
> little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc.
> with OpenSSL. They have all the format "c=US, o=VeriSign, ..."
> (openssl-*/cerst/). All these trustcenters use LDAP-servers but these
> DNs can never be stored in a directoryserver!
>
> So it looks like OpenSSL displays the different parts of a DN in the
> wrong order. Did I make a misinterpretation? If this is a bug then I
> have the next question, can you fix this in the 0.9.7-tree?
>

i looked into the signers certs in netscape - and the certs are identical (
OpenCA, Entrust,... ). Maybe only a display error from openssl ?

Robert

>
> It is possible to protect the old index.txt etc. by adding an option
> -x500 or something like this to get a DN which can be inserted in a
> directoryserver. The problem is that OpenSSL interprets a correct DN
> with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a
> "wrong" certificate).
>
> I know no optimal solution except of adding such an option to every
> related command or add an option like -oldstyledn to "openssl x509" and
> "openssl ca" but before starting discussing solutions I will wait for an
> answer (bug or misinterpretation).
>
> Best Regards, Michael
> --
> ---
> Michael Bell   Email (private): [EMAIL PROTECTED]
> Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
> Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
> Unter den Linden 6 Fax:  +49 (0)30-2093 2959
> 10099 Berlin
> Germany   http://www.openca.org
>
> ___
> Openca-Users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/openca-users
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

patch for req/ca -subj (was: Re: Wrong DNs)

[Robert Joop]

  STRTOK(3)   Linux Programmer's Manual   STRTOK(3)

  NAME
strtok, strtok_r - extract tokens from strings

  BUGS
Never use these functions.
^^

no, i'm not making this up, this is a vanilla debian woody.

On 02-04-17 12:41:35 CEST, Robert Joop wrote:
> On 02-04-16 19:04:41 CEST, Michael Bell wrote:
> > The only bad detail is now "openssl -subj" which use a DN with ","
> > inside but the order is the one from X.500.
> 
> looking at last night's snap, apps/req.c, build_subject(), i see that
> one can use both , and / delimiters.
> but i fail to see whether one can escape the delimiters. can one?

one cannot, it uses strtok...

i've souped it up a little, so that now the args for req -subj and ca
-subj can contain escaped characters, e.g. req -subj
'/C=US/CN=John\/Jane Doe'.

except for the escaping, this is the format used by openssl in
index.txt...

this is also the format that will be emitted by openca when it interfaces
to openssl:

use X500::DN;
my $dn = new X500::DN (new X500::RDN ('c'=>'US'), new X500::RDN ('o'=>'\\Acme/2, 
Inc.'), new X500::RDN ('cn'=>'John Doe, PhD')) or die;
print $dn->getRFC2253String(), "\n";
print $dn->getOpenSSLString(), "\n";

outputs:

cn=John Doe\, PhD, o=\\Acme/2\, Inc., c=US
/c=US/o=\\Acme\/2, Inc./cn=John Doe, PhD

a patch (based on openssl-SNAP-20020423) is attached.

rj


diff -ru orig/openssl-SNAP-20020423/apps/ca.c openssl-SNAP-20020423/apps/ca.c
--- orig/openssl-SNAP-20020423/apps/ca.cFri Mar  8 21:00:46 2002
+++ openssl-SNAP-20020423/apps/ca.c Wed Apr 24 15:49:55 2002
@@ -3023,64 +3023,122 @@
return ret;
}
 
+/*
+ * subject is expected to be in the format /type0=value0/type1=value1/type2=...
+ * where characters may be escaped by \
+ */
 static X509_NAME *do_subject(char *subject)
{
-   X509_NAME *n = NULL;
-
-   int i, nid, ne_num=0;
+   size_t buflen = strlen (subject)+1; /* to copy the types and values into. due 
+to escaping, the copy can only become shorter */
+   char *buf = malloc (buflen);
+   size_t max_ne = buflen / 2 + 1; /* maximum number of name elements */
+   char **ne_types = malloc (max_ne * sizeof (char *));
+   char **ne_values = malloc (max_ne * sizeof (char *));
 
-   char *ne_name = NULL;
-   char *ne_value = NULL;
+   char *sp = subject, *bp = buf;
+   int i, ne_num = 0;
 
-   char *tmp = NULL;
-   char *p[2];
+   X509_NAME *n = NULL;
+   int nid;
 
-   char *str_list[256];
-   
-   p[0] = ",/";
-   p[1] = "=";
+   if (!buf || !ne_types || !ne_values)
+   {
+   BIO_printf(bio_err, "malloc error\n");
+   goto error0;
+   }
 
-   n = X509_NAME_new();
+   if (*subject != '/')
+   {
+   BIO_printf(bio_err, "Subject does not start with '/'.\n");
+   goto error0;
+   }
+   sp++; /* skip leading / */
 
-   tmp = strtok(subject, p[0]);
-   while((tmp != NULL) && (ne_num < (sizeof str_list/sizeof *str_list)))
+   while (*sp)
+   {
+   /* collect type */
+   ne_types[ne_num] = bp;
+   while (*sp)
{
-   char *token = tmp;
-
-   while (token[0] == ' ')
-   token++;
-   str_list[ne_num] = token;
-
-   tmp = strtok(NULL, p[0]);
-   ne_num++;
+   if (*sp == '\\') /* is there anything to escape in the 
+type...? */
+   if (*++sp)
+   *bp++ = *sp++;
+   else
+   {
+   BIO_printf(bio_err, "escape character at end 
+of string\n");
+   goto error0;
+   }
+   else if (*sp == '=')
+   {
+   sp++;
+   *bp++ = '\0';
+   break;
+   }
+   else
+   *bp++ = *sp++;
}
+   if (!*sp)
+   {
+   BIO_printf(bio_err, "end of string encountered while 
+processing type of subject name element #%d\n", ne_num);
+   goto error0;
+   }
+   ne_values[ne_num] = bp;
+   while (*sp)
+   {
+   if (*sp == '\\')
+   if (*++sp)
+   *bp++ = *sp++;
+   else
+   {
+   BIO_printf(bio_err, "escape character at end 
+of string\n");
+   goto error0;
+   }
+   else if (*sp == '/')
+