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
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
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),
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
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
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
-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)
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
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
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
-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
-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
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
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
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,
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
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.
--
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
-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
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:
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:
21 matches
Mail list logo
