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
On Tue, Apr 16, 2002 at 09:06:01AM +1000, Steven Reddie wrote:
Perhaps blocking attachments on the current lists, and setting up an
additional openssl-patches list that accepts attachments would work. Most
people would not bother subscribing to the patches list anyway.
Steven
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
Hi Guys,
Here's a question for the experts
and before you ask the reason why we want to do it is because it's a good
idea
We have a new business naming scheme that looks like this:
McDonalds@tampa(fl-us)
where McDonalds is the business name, tampa is the town, fl is the state
code
-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
On Mon, Apr 15, 2002 at 11:23:49PM +0200, David Maurus wrote:
Andreas Sterbenz wrote:
For the Sun JSSE provider, the default enabled protocols are SSLv3,
TLSv1, and the pseudo protocol SSLv2Hello. The latter means that client
hello messages are sent/ accepted in SSLv2 format. This is for
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
Hi,
I'm currently working on a port of OpenSSL (0.9.6) to the AS/400. The first
part of this project, getting the code to compile, has gone much better than
I expected, largely due to IBM's GNU utilities which provide a more
UNIX-like build environment than before.
I've only done a couple of
This does break the naming recommendations given in X.521 Annex B
though, which don't allow for a stateOrProvinceName.
Yes, of course. The old Annex B, we obviously forgot about that one.
- Original Message -
From: Oscar Jacobsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; David Lyon
In file: pkcs12.c, function: dump_certs_pkeys_bag, at case
NID_pkcs8ShroudedKeyBag
if EVP_PKCS82PKEY (p8) fails (line 640),
EVP_PKEY_free(pkey) (line 644) is not called.
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
At 10:20 16.04.2002 +0100, you wrote:
If I build openssl with CHARSET_EBCDIC not defined, it fails to recognise a
certificate, presumably because it fails to find the -BEGIN
CERTIFICATE- string. With CHARSET_EBCDIC defined, I get a Base64
decode error, presumably because the encrypted
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
22 matches
Mail list logo
