Re: [openssl-dev] Creating requests and certificates with Subject Alternative Names
> I'm creating X509 certificate requests and certificates in code, > trying to add X509v3 Subject Alternative Name, with 1.1.0f. > > But if I add a list of four domains, ie: > The certificate seems to ignore some and repeat others: To answer my own question, I was using ASN1_STRING_set0 instead of ASN1_STRING_set and the original ANSI string was a temporary variable, so got lost as a new string was added since it was not copied. But there must be an easier way of adding SANs to certificates than using undocumented GENERAL_NAME APIs. Angus -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
Open device for new account thank you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Does OpenSSL support the extension 'subject directory attributes'?
Dear everyone,
I am using PyOpenSSL which is the thin wrapper of OpenSSL to add the
extension 'subject directory attributes' to a certificate by a Python
program. The extension names 'subjectDirAttrs' and
'subjectDirectoryAttributes' have been tried but the error occurs:
"OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown
extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in
extension')]".
As PyOpenSSL is the wrapper of OpenSSL, can anyone make it clear
that whether OpenSSL supports the extension 'subject directory attributes'
and what is the proper name in programming if OpenSSL supports it?
The other question is the error is reported as follows when I add
the extension 'certificate policies' to a certificate by PyOpenSSL.
"OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no
config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in
extension')]"
What is the config database? Does it refer to
/usr/local/ssl/openssl.cnf? How to use it to add the extension
'certificate policies' to a certificate by PyOpenSSL?
Many thanks!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3136] [PATCH] get rid of extra space when printing -subject and -issuer in x509
commit fb0303f in master. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3136 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
Hi I am trying to test behaviour of Openssl in resumption rejection case. I am using with Openssl-1.1.0 pre2 version. When using Openssl as client and other ssl library as server, Initially client and server accepts on resumption, later server expects client rejected the resumption and sends server hello with different protocol version and cipher suite. What will be behaviour of Openssl in this case? when I test this on Openssl I get wrong ssl version error. But, When I run same thing on Broingssl, I get no error, handshake was success full with new protocol version. Can someone help me with this? Thank you Durga. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
On Wed Aug 05 01:06:40 2015, m...@bogosian.net wrote: Hi Steve, I've attached three certificate collections: two that fail (where subject == issuer) and one that works around the problem (where subject != issuer). OK thanks for the examples. The bug is that OpenSSL 1.0.2 is less strict about what counts as a valid self signed certificate. Before 1.0.2 the certificate had to have issuer and subject matching, if present AKID==SKID and keyUsage (if present) had to include keyCertSign. For1.0.2 and later the keyCertSign check is no longer present. The attached patch should fix it. Let me know if it works for you. A workaround (other than making subject != issuer) is to include SKID/AKID in all certificates. Regards, Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org diffs.ss Description: Binary data ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
On Tue Aug 04 18:25:25 2015, m...@bogosian.net wrote: Please let me know if you have any questions, and I'd be happy to elaborate. Can you attach examples of the two certificates (EE and CA) that exhibit this problem? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Later versions[1] of OpenSSL will (mistakenly) complain that if subject text == issuer text, then the certificate is self-signed (even if it isn't). [1] I haven't narrowed down exactly which; 0.9.8 and 1.0.0 generally don't exhibit this problem, whereas 1.0.1 and 1.0.2 generally do. A more detailed explanation (with examples) can be found here: https://github.com/docker/compose/issues/890#issuecomment-127662092 Please let me know if you have any questions, and I'd be happy to elaborate. Sincerely, Matt Bogosian +1.831.824.4442 signature.asc Description: PGP signature ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Hi Steve, I've attached three certificate collections: two that fail (where subject == issuer) and one that works around the problem (where subject != issuer). In my personal testing (on OS X), OpenSSL 0.9.8zd (installed by the OS) works on all three collections, whereas OpenSSL 1.0.2d (installed via MacPorts) fails on the fail*.tar.gz ones. You can see the problem with the following: % tar xpvf ~/Desktop/fail1.tar.gz x tls/ x tls/ca.pem x tls/cakey.pem x tls/cert.pem x tls/hostnames x tls/key.pem x tls/server.pem x tls/serverkey.pem % openssl s_server -www -key tls/serverkey.pem -cert tls/server.pem \ -CAfile tls/ca.pem -tls1 ... % openssl-0.9.8zd s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # works depth=1 /O=Boot2Docker verify return:1 depth=0 /O=Boot2Docker verify return:1 ... % openssl-1.0.2d s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # fails depth=0 O = Boot2Docker verify error:num=18:self signed certificate verify return:1 depth=0 O = Boot2Docker verify error:num=21:unable to verify the first certificate verify return:1 ... % tar xpvf ~/Desktop/fail2.tar.gz x tls/ x tls/ca.pem x tls/cakey.pem x tls/cert.pem x tls/hostnames x tls/key.pem x tls/server.pem x tls/serverkey.pem % openssl s_server -www -key tls/serverkey.pem -cert tls/server.pem \ -CAfile tls/ca.pem -tls1 ... % openssl-0.9.8zd s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # works depth=1 /O=b2d verify return:1 depth=0 /O=b2d verify return:1 ... % openssl-1.0.2d s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # fails depth=0 O = b2d verify error:num=18:self signed certificate verify return:1 depth=0 O = b2d verify error:num=21:unable to verify the first certificate verify return:1 ... % tar xpvf ~/Desktop/succ.tar.gz x tls/ x tls/ca.pem x tls/cakey.pem x tls/cert.pem x tls/hostnames x tls/key.pem x tls/server.pem x tls/serverkey.pem % openssl s_server -www -key tls/serverkey.pem -cert tls/server.pem \ -CAfile tls/ca.pem -tls1 ... % openssl-0.9.8zd s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # works depth=1 /O=Boot2DockerCA verify return:1 depth=0 /O=Boot2Docker verify return:1 ... % openssl-1.0.2d s_client -showcerts -connect localhost:4433 -key tls/key.pem \ -cert tls/cert.pem -CAfile tls/ca.pem -tls1 /dev/null # works depth=1 O = Boot2DockerCA verify return:1 depth=0 O = Boot2Docker verify return:1 ... —Matt On Aug 4, 2015, at 17:05, Stephen Henson via RT r...@openssl.org wrote: On Tue Aug 04 18:25:25 2015, m...@bogosian.net wrote: Please let me know if you have any questions, and I'd be happy to elaborate. Can you attach examples of the two certificates (EE and CA) that exhibit this problem? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org fail1.tar.gz Description: GNU Zip compressed data fail2.tar.gz Description: GNU Zip compressed data succ.tar.gz Description: GNU Zip compressed data signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] (no subject)
Hi guys, Im having trouble on creating a Self-Signed Certificate on a Windows CE 6.0 device. I posted a question on stackoverflow but until now only one person posted a comment. Can you give more details? The post is: http://stackoverflow.com/questions/31339690/asn1-time-wrong-on-windows-ce-6-0 Thanks in advance ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
On 5/31/2015 2:46 AM, noloa...@gmail.com via RT wrote:
apps.c has a couple of parsing routines called load_pubkey and
load_key. rsautl uses those routines.
However, there's no option in rsautil to use anything other than a
ASN.1/DER or PEM encoded traditional key (or subject public key info).
The code paths are present, we just can't seem to get to them.
The load_pubkey already has code to support FORMAT_PEMRSA
and call PEM_read_bio_RSAPublicKey
Looking at OpenSSL 1.0.2, it looks like the problem is more in
apps.c in the str2fmt that does not have an option to set FORMAT_PEMRSA
or FORMAT_ASN1RSA.
Folks in the field have problem with it on occasion. See, for example,
Can't load programmatically generated public key,
http://stackoverflow.com/q/30547646.
This patch adds an intelligent fallback:
/* rsautl does not offer a way to specify just a public key. It
requires a */
/* subjectPublicKeyInfo, and there's no argument or option to
switch to */
/* the other type with either ASN.1/DER or PEM. This attempts to
make an */
/* intelligent retry. */
if(keyformat == FORMAT_PEM) {
next_format = FORMAT_PEMRSA;
} if(keyformat == FORMAT_ASN1) {
next_format = FORMAT_ASN1RSA;
} else {
next_format = -1;
}
switch (key_type) {
case KEY_PRIVKEY:
pkey = load_key(keyfile, keyformat, 0, passin, e, Private
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_key(keyfile,
next_format, 0, passin, e, Private Key, 1 /*last_try*/); }
break;
case KEY_PUBKEY:
pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, Public
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_pubkey(keyfile,
next_format, 0, NULL, e, Public Key, 1 /*last_try*/); }
break;
Then, functions load_key and load_pubkey suppress the error messages
if last_try is 0:
if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
}
All in all, existing behavior and error messages are maintained. The
subcommand is just a little more robust.
Related, we might be able to make similar changes to rsa.c. But
there's some extra special sauce present, so it was not a clear
cut-in. I think the special sauce kid of attempts to do the same thing
as above. (Maybe this patch should act more like rsa.c?)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
--
Douglas E. Engert deeng...@gmail.com
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT r...@openssl.org
wrote:
Nice idea, I'm however thinking that much of the trying different formats
could
be moved to load_key / load_pubkey, all that would be needed is a keyformat
denoting try anything. -1, perhaps?
I like the idea, and I was entertaining it. The goal here ways to
improve rsautl, so I deferred.
There are some potential issues with moving the logic into load_key
and load_pubkey. The first issue is the change in behavior utility
wide. That is, it will affect most (all?) utilities. I think its a
good idea, but others may not.
The second issue (related to the first), is the rsa utility has tried
to address these issue already. So there's a few other
switches/options for the rsa utility. For example, RSAPublicKey_in and
RSAPublicKey_out. This may or may not be an issue.
The third issue (related to the first), is that other similar
functions, like load_certificate, may not get the change. This may or
may not matter, and may or may not be an issue.
The fourth issue is the cracker. Effectively, apps{c|h} only
recognizes PEM, PEMRSA, ASN1, and ASN1RSA (see str2fmt, which appears
to be removed in 1.1.0). So OpenSSL would need a way to identify other
encodings, types and algorithms. For example, a PEM encoded DSA
SubjectPublicKeyInfo or PrivateKeyInfo (traditional key) versus a
ANS.1/DER encoded DSA public key or private key.
**
I think there's little difference between load_key and load_pubkey.
Fold them together, and call the function that remains load_key and
return the EVP_PKEY.
load_key should take a encoding hint (PEM vs ASN.1, etc), a key type
hint (SPKI/Traditional versus Key-Only, etc), a key pair hint (public
versus private), and a key algorithm hint (RSA, DSA, etc).
I would envision it to be similar to:
int encoding_hint = -1, key_type_hint = -1, key_pair_hint = -1,
key_alg_hint = -1;
key_hints(…, encoding_hint, key_type_hint, key_pair_hint, key_alg_hint);
That's going to lead to an ugly message cracker, but I don't know how
to avoid it.
**
There is a key_file_format function in apps.c, but its not really
useful. I think this is the keystone to making things work here. It
should peek at the key, and return the tuple {key encoding, key type,
key pair, key algorithm} hints. Its similar to str2fmt, but it works
directly with the key specified by the user rather than command line
arguments.
One of the things I give the user credit for is that they know the
key-file they want to use. They may not know the encoding, format or
type - but they know the filename. So something to peek into the file
and then make intelligent decisions would probably be very helpful to
the user.
I understand key_file_format won't work with stdin. So maybe the
course of action is to peek from a BIO. If its a file BIO, then
everything just works. If its from stdin, then wrap it in a memory bio
so everything works as expected.
**
Jeff
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT r...@openssl.org
wrote:
Nice idea, I'm however thinking that much of the trying different formats
could
be moved to load_key / load_pubkey, all that would be needed is a keyformat
denoting try anything. -1, perhaps?
I like the idea, and I was entertaining it. The goal here ways to
improve rsautl, so I deferred.
There are some potential issues with moving the logic into load_key
and load_pubkey. The first issue is the change in behavior utility
wide. That is, it will affect most (all?) utilities. I think its a
good idea, but others may not.
The second issue (related to the first), is the rsa utility has tried
to address these issue already. So there's a few other
switches/options for the rsa utility. For example, RSAPublicKey_in and
RSAPublicKey_out. This may or may not be an issue.
The third issue (related to the first), is that other similar
functions, like load_certificate, may not get the change. This may or
may not matter, and may or may not be an issue.
The fourth issue is the cracker. Effectively, apps{c|h} only
recognizes PEM, PEMRSA, ASN1, and ASN1RSA (see str2fmt, which appears
to be removed in 1.1.0). So OpenSSL would need a way to identify other
encodings, types and algorithms. For example, a PEM encoded DSA
SubjectPublicKeyInfo or PrivateKeyInfo (traditional key) versus a
ANS.1/DER encoded DSA public key or private key.
**
I think there's little difference between load_key and load_pubkey.
Fold them together, and call the function that remains load_key and
return the EVP_PKEY.
load_key should take a encoding hint (PEM vs ASN.1, etc), a key type
hint (SPKI/Traditional versus Key-Only, etc), a key pair hint (public
versus private), and a key algorithm hint (RSA, DSA, etc).
I would envision it to be similar to:
int encoding_hint = -1, key_type_hint = -1, key_pair_hint = -1,
key_alg_hint = -1;
key_hints(…, encoding_hint, key_type_hint, key_pair_hint, key_alg_hint);
That's going to lead to an ugly message cracker, but I don't know how
to avoid it.
**
There is a key_file_format function in apps.c, but its not really
useful. I think this is the keystone to making things work here. It
should peek at the key, and return the tuple {key encoding, key type,
key pair, key algorithm} hints. Its similar to str2fmt, but it works
directly with the key specified by the user rather than command line
arguments.
One of the things I give the user credit for is that they know the
key-file they want to use. They may not know the encoding, format or
type - but they know the filename. So something to peek into the file
and then make intelligent decisions would probably be very helpful to
the user.
I understand key_file_format won't work with stdin. So maybe the
course of action is to peek from a BIO. If its a file BIO, then
everything just works. If its from stdin, then wrap it in a memory bio
so everything works as expected.
**
Jeff
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
I submitted this earlier, but I forgot to tweak the docs. The docs
were missing the -keyform option, and they needed the behavior change
documented.
I also fixed a typo in the patch. The following was missing an 'else if':
if(keyformat == FORMAT_PEM) {
next_format = FORMAT_PEMRSA;
} else if(keyformat == FORMAT_ASN1) {
next_format = FORMAT_ASN1RSA;
} else {
next_format = -1;
}
Attached is the updated patch.
If the patch is rejected, you might consider taking the documentation
updates (sans the behavioral changes).
On Sat, May 30, 2015 at 6:17 PM, Jeffrey Walton noloa...@gmail.com wrote:
apps.c has a couple of parsing routines called load_pubkey and
load_key. rsautl uses those routines.
However, there's no option in rsautil to use anything other than a
ASN.1/DER or PEM encoded traditional key (or subject public key info).
The code paths are present, we just can't seem to get to them.
...
diff --git a/apps/apps.c b/apps/apps.c
index 60f71c3..f80767a 100644
--- a/apps/apps.c
+++ b/apps/apps.c
@@ -763,7 +763,7 @@ X509_CRL *load_crl(const char *infile, int format)
}
EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip)
+ const char *pass, ENGINE *e, const char *key_descrip, int
last_try)
{
BIO *key = NULL;
EVP_PKEY *pkey = NULL;
@@ -773,7 +773,7 @@ EVP_PKEY *load_key(const char *file, int format, int
maybe_stdin,
cb_data.prompt_info = file;
if (file == NULL (!maybe_stdin || format == FORMAT_ENGINE)) {
-BIO_printf(bio_err, no keyfile specified\n);
+if(last_try) { BIO_printf(bio_err, no keyfile specified\n); }
goto end;
}
#ifndef OPENSSL_NO_ENGINE
@@ -827,7 +827,7 @@ EVP_PKEY *load_key(const char *file, int format, int
maybe_stdin,
}
end:
BIO_free(key);
-if (pkey == NULL) {
+if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
ERR_print_errors(bio_err);
}
@@ -842,7 +842,7 @@ static const char *key_file_format(int format)
}
EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip)
+ const char *pass, ENGINE *e, const char *key_descrip,
int last_try)
{
BIO *key = NULL;
EVP_PKEY *pkey = NULL;
@@ -852,7 +852,7 @@ EVP_PKEY *load_pubkey(const char *file, int format, int
maybe_stdin,
cb_data.prompt_info = file;
if (file == NULL (!maybe_stdin || format == FORMAT_ENGINE)) {
-BIO_printf(bio_err, no keyfile specified\n);
+if(last_try) { BIO_printf(bio_err, no keyfile specified\n); }
goto end;
}
#ifndef OPENSSL_NO_ENGINE
@@ -914,8 +914,9 @@ EVP_PKEY *load_pubkey(const char *file, int format, int
maybe_stdin,
#endif
end:
BIO_free(key);
-if (pkey == NULL)
+if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
+}
return (pkey);
}
diff --git a/apps/apps.h b/apps/apps.h
index a8652a1..0cd563a 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -427,9 +427,9 @@ X509 *load_cert(const char *file, int format,
X509_CRL *load_crl(const char *infile, int format);
int load_cert_crl_http(const char *url, X509 **pcert, X509_CRL **pcrl);
EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip);
+ const char *pass, ENGINE *e, const char *key_descrip, int
last_try);
EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip);
+ const char *pass, ENGINE *e, const char *key_descrip,
int last_try);
STACK_OF(X509) *load_certs(const char *file, int format,
const char *pass, ENGINE *e,
const char *cert_descrip);
diff --git a/apps/ca.c b/apps/ca.c
index 4dc9176..8c03efd 100644
--- a/apps/ca.c
+++ b/apps/ca.c
@@ -587,7 +587,7 @@ end_of_options:
goto end;
}
}
-pkey = load_key(keyfile, keyformat, 0, key, e, CA private key);
+pkey = load_key(keyfile, keyformat, 0, key, e, CA private key, 1
/*last_try*/);
if (key)
OPENSSL_cleanse(key, strlen(key));
if (pkey == NULL) {
diff --git a/apps/cms.c b/apps/cms.c
index 7ccca5b..5966873 100644
--- a/apps/cms.c
+++ b/apps/cms.c
@@ -762,7 +762,7 @@ int cms_main(int argc, char **argv)
keyfile = NULL;
if (keyfile) {
-key = load_key(keyfile, keyform, 0, passin, e, signing key file);
+key = load_key(keyfile, keyform, 0, passin, e, signing key file, 1
/*last_try*/);
if (!key)
goto end;
}
@@ -966,7 +966,7 @@ int cms_main(int argc, char **argv)
e, signer certificate);
if (!signer
[openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
Nice idea, I'm however thinking that much of the trying different formats could
be moved to load_key / load_pubkey, all that would be needed is a keyformat
denoting try anything. -1, perhaps?
On Sun May 31 09:46:28 2015, noloa...@gmail.com wrote:
apps.c has a couple of parsing routines called load_pubkey and
load_key. rsautl uses those routines.
However, there's no option in rsautil to use anything other than a
ASN.1/DER or PEM encoded traditional key (or subject public key info).
The code paths are present, we just can't seem to get to them.
Folks in the field have problem with it on occasion. See, for example,
Can't load programmatically generated public key,
http://stackoverflow.com/q/30547646.
This patch adds an intelligent fallback:
/* rsautl does not offer a way to specify just a public key. It
requires a */
/* subjectPublicKeyInfo, and there's no argument or option to
switch to */
/* the other type with either ASN.1/DER or PEM. This attempts to
make an */
/* intelligent retry. */
if(keyformat == FORMAT_PEM) {
next_format = FORMAT_PEMRSA;
} if(keyformat == FORMAT_ASN1) {
next_format = FORMAT_ASN1RSA;
} else {
next_format = -1;
}
switch (key_type) {
case KEY_PRIVKEY:
pkey = load_key(keyfile, keyformat, 0, passin, e, Private
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_key(keyfile,
next_format, 0, passin, e, Private Key, 1 /*last_try*/); }
break;
case KEY_PUBKEY:
pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, Public
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_pubkey(keyfile,
next_format, 0, NULL, e, Public Key, 1 /*last_try*/); }
break;
Then, functions load_key and load_pubkey suppress the error messages
if last_try is 0:
if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
}
All in all, existing behavior and error messages are maintained. The
subcommand is just a little more robust.
Related, we might be able to make similar changes to rsa.c. But
there's some extra special sauce present, so it was not a clear
cut-in. I think the special sauce kid of attempts to do the same thing
as above. (Maybe this patch should act more like rsa.c?)
--
Richard Levitte
levi...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails
apps.c has a couple of parsing routines called load_pubkey and
load_key. rsautl uses those routines.
However, there's no option in rsautil to use anything other than a
ASN.1/DER or PEM encoded traditional key (or subject public key info).
The code paths are present, we just can't seem to get to them.
Folks in the field have problem with it on occasion. See, for example,
Can't load programmatically generated public key,
http://stackoverflow.com/q/30547646.
This patch adds an intelligent fallback:
/* rsautl does not offer a way to specify just a public key. It
requires a */
/* subjectPublicKeyInfo, and there's no argument or option to
switch to */
/* the other type with either ASN.1/DER or PEM. This attempts to
make an */
/* intelligent retry. */
if(keyformat == FORMAT_PEM) {
next_format = FORMAT_PEMRSA;
} if(keyformat == FORMAT_ASN1) {
next_format = FORMAT_ASN1RSA;
} else {
next_format = -1;
}
switch (key_type) {
case KEY_PRIVKEY:
pkey = load_key(keyfile, keyformat, 0, passin, e, Private
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_key(keyfile,
next_format, 0, passin, e, Private Key, 1 /*last_try*/); }
break;
case KEY_PUBKEY:
pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, Public
Key, 0 /*last_try*/);
if(!pkey next_format != -1) { pkey = load_pubkey(keyfile,
next_format, 0, NULL, e, Public Key, 1 /*last_try*/); }
break;
Then, functions load_key and load_pubkey suppress the error messages
if last_try is 0:
if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
}
All in all, existing behavior and error messages are maintained. The
subcommand is just a little more robust.
Related, we might be able to make similar changes to rsa.c. But
there's some extra special sauce present, so it was not a clear
cut-in. I think the special sauce kid of attempts to do the same thing
as above. (Maybe this patch should act more like rsa.c?)
diff --git a/apps/apps.c b/apps/apps.c
index 60f71c3..f80767a 100644
--- a/apps/apps.c
+++ b/apps/apps.c
@@ -763,7 +763,7 @@ X509_CRL *load_crl(const char *infile, int format)
}
EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip)
+ const char *pass, ENGINE *e, const char *key_descrip, int
last_try)
{
BIO *key = NULL;
EVP_PKEY *pkey = NULL;
@@ -773,7 +773,7 @@ EVP_PKEY *load_key(const char *file, int format, int
maybe_stdin,
cb_data.prompt_info = file;
if (file == NULL (!maybe_stdin || format == FORMAT_ENGINE)) {
-BIO_printf(bio_err, no keyfile specified\n);
+if(last_try) { BIO_printf(bio_err, no keyfile specified\n); }
goto end;
}
#ifndef OPENSSL_NO_ENGINE
@@ -827,7 +827,7 @@ EVP_PKEY *load_key(const char *file, int format, int
maybe_stdin,
}
end:
BIO_free(key);
-if (pkey == NULL) {
+if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
ERR_print_errors(bio_err);
}
@@ -842,7 +842,7 @@ static const char *key_file_format(int format)
}
EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip)
+ const char *pass, ENGINE *e, const char *key_descrip,
int last_try)
{
BIO *key = NULL;
EVP_PKEY *pkey = NULL;
@@ -852,7 +852,7 @@ EVP_PKEY *load_pubkey(const char *file, int format, int
maybe_stdin,
cb_data.prompt_info = file;
if (file == NULL (!maybe_stdin || format == FORMAT_ENGINE)) {
-BIO_printf(bio_err, no keyfile specified\n);
+if(last_try) { BIO_printf(bio_err, no keyfile specified\n); }
goto end;
}
#ifndef OPENSSL_NO_ENGINE
@@ -914,8 +914,9 @@ EVP_PKEY *load_pubkey(const char *file, int format, int
maybe_stdin,
#endif
end:
BIO_free(key);
-if (pkey == NULL)
+if (pkey == NULL last_try) {
BIO_printf(bio_err, unable to load %s\n, key_descrip);
+}
return (pkey);
}
diff --git a/apps/apps.h b/apps/apps.h
index a8652a1..0cd563a 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -427,9 +427,9 @@ X509 *load_cert(const char *file, int format,
X509_CRL *load_crl(const char *infile, int format);
int load_cert_crl_http(const char *url, X509 **pcert, X509_CRL **pcrl);
EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip);
+ const char *pass, ENGINE *e, const char *key_descrip, int
last_try);
EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
- const char *pass, ENGINE *e, const char *key_descrip);
+ const char *pass, ENGINE *e, const char *key_descrip,
int last_try);
STACK_OF(X509) *load_certs(const char
[openssl-dev] [openssl.org #3789] CMS: Segmentation fault when using subject key identifier and EC
Hi, OpenSSL segfaults when trying to create an encrypted CMS data envelope using subject key identifier and EC. Have tested this in version 1.0.2a and latest 1.1.0 release as of today (2015-04-09) with the same result. Example: $ openssl version OpenSSL 1.0.2a 19 Mar 2015 $ openssl ecparam -name prime192v1 -genkey -out ec.key $ openssl req -x509 -new -key ec.key -out ec.crt You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []: Email Address []: $ echo Text to encrypt text.txt $ openssl cms -encrypt -keyid -in text.txt -outform DER -recip ec.crt -out out.dat Segmentation fault: 11 If I remove the 'keyid' switch it will work as expected. Best regards, Jonas Peterson ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Test, please ignore ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve
Nevermind, I just realized that it is using Client certificate there and doesn't needs to be asyncified. On Fri, Aug 29, 2014 at 12:54 AM, Fedor Indutny fe...@indutny.com wrote: Oh, and I have just realized that it doesn't handle `ssl3_get_cert_verify` case right now. I'll figure it out tomorrow. On Thu, Aug 28, 2014 at 2:26 PM, Fedor Indutny fe...@indutny.com wrote: Hello again! Here is a second patch that improves the first one. Additionally it copies and restores the packet data before/after calling out async callback. However it is almost evident for me that nothing could overwrite `s-init_buf-data` during async handshake, so if you feel confident about it - please let me know and I will revert everything except style changes in that 0002 patch. Cheers, Fedor. On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny fe...@indutny.com wrote: Oops, just realized that I pasted whole commit message into a subject. Anyway, CCing Rich Salz here. Rich, You seem to be on a wave on triaging tickets, may be you could take a look at this one eventually? Thank you, Fedor. On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny fe...@indutny.com wrote: This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162
Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve
Hello again! Here is a second patch that improves the first one. Additionally it copies and restores the packet data before/after calling out async callback. However it is almost evident for me that nothing could overwrite `s-init_buf-data` during async handshake, so if you feel confident about it - please let me know and I will revert everything except style changes in that 0002 patch. Cheers, Fedor. On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny fe...@indutny.com wrote: Oops, just realized that I pasted whole commit message into a subject. Anyway, CCing Rich Salz here. Rich, You seem to be on a wave on triaging tickets, may be you could take a look at this one eventually? Thank you, Fedor. On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny fe...@indutny.com wrote: This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162 0002-ssl-copy-packet-before-performing-async-key-ex.patch.sig Description: Binary data 0002-ssl-copy-packet-before-performing-async-key-ex.patch Description: Binary data
Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve
Oh, and I have just realized that it doesn't handle `ssl3_get_cert_verify` case right now. I'll figure it out tomorrow. On Thu, Aug 28, 2014 at 2:26 PM, Fedor Indutny fe...@indutny.com wrote: Hello again! Here is a second patch that improves the first one. Additionally it copies and restores the packet data before/after calling out async callback. However it is almost evident for me that nothing could overwrite `s-init_buf-data` during async handshake, so if you feel confident about it - please let me know and I will revert everything except style changes in that 0002 patch. Cheers, Fedor. On Wed, Aug 27, 2014 at 1:05 PM, Fedor Indutny fe...@indutny.com wrote: Oops, just realized that I pasted whole commit message into a subject. Anyway, CCing Rich Salz here. Rich, You seem to be on a wave on triaging tickets, may be you could take a look at this one eventually? Thank you, Fedor. On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny fe...@indutny.com wrote: This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162
Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve
Oops, just realized that I pasted whole commit message into a subject. Anyway, CCing Rich Salz here. Rich, You seem to be on a wave on triaging tickets, may be you could take a look at this one eventually? Thank you, Fedor. On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny fe...@indutny.com wrote: This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162
Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server wi
This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Server will ignore dummy RSA key, assuming that it is matching the certificate. * Server will invoke this callback with either: * `SSL_KEY_EX_RSA` * `SSL_KEY_EX_RSA_SIGN` as a `type` argument, and some data for signature or decryption in `p`/`n` pair. At that time the sign/decryption may be performed on any thread, or even remotely, and the result should be supplied with `SSL_supply()`. Calling `SSL_supply()` will continue the handshake process without even touching the real private key. NOTE: The test is missing right now, I'll add it once we will figure out how the API should look like. Implementation appears to be working when used with node.js, see https://github.com/indutny/node/tree/feature/async-key-exchange and https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing. ANOTHER NOTE: Pull Request on github: https://github.com/openssl/openssl/pull/162 0001-ssl-introduce-async-sign-decrypt-APIs.patch Description: Binary data 0001-ssl-introduce-async-sign-decrypt-APIs.patch.sig Description: Binary data
Query reg multiple CA-Cert in list with same subject
Hi, I have a query for Ca-Cert list. If at gateway we have configured two CA-certs A1 and A2 both having same subject and content except time-stamp of generation. If peer sends Cert matching to A2, gateway tries to validate it with A1(subject being same and configured first in list) and validation fails. 1. is there a way to avoid addition of cert in store if subject and all contents are same except timestamp generation. 2. Or if not 1st, is there way to validate incoming cert with both cert configured in store. Thanks
Query reg multiple CA-Cert in list with same subject
Hi, I have a query for Ca-Cert list. If at gateway we have configured two CA-certs A1 and A2 both having same subject and content except time-stamp of generation. If peer sends Cert matching to A2, gateway tries to validate it with A1(subject being same and configured first in list) and validation fails. 1. is there a way to avoid addition of cert in store if subject and all contents are same except timestamp generation. 2. Or if not 1st, is there way to validate incoming cert with both cert configured in store. Thanks Mukesh
Re: The new subject hash algorithm
Hi Steve and Krzysztof, I have not been able to reproduce the same output as openssl. Can you be more specific how you achieved it? So x509_name_canon generates the CANONICAL representation of the subject name, right? If I understand correctly, after generating the canon encoding I would only have to pass it to EVP_Digest, correct? Exposing x509_name_canon() to x509_cmp.c first. unsigned long X509_NAME_hash(X509_NAME *x): x509_name_canon() EVP_Digest(x-canon_enc, x-canon_enclen, md, NULL, EVP_sha1(), NULL) -- View this message in context: http://openssl.6102.n7.nabble.com/The-new-subject-hash-algorithm-tp44844p46720.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3136] [PATCH] get rid of extra space when printing -subject and -issuer in x509
Openssl behaves differently when printing subject or issuer from request
or from existing certificate in x509. If using x509 there is an extra
space after '=' character.
It can affect scripts that checks whether these fields in request and
certificate match. Moreover when printing serial, the in x509 there was
no extra space, so the behavior was kind of unpredictable. The attached
patch deletes the extra space in x509 output.
Jiri Horky
--- apps/x509.c 2013-10-03 13:42:39.504547535 +0200
+++ apps/x509.c.orig 2013-10-03 13:42:25.784301201 +0200
@@ -728,12 +728,12 @@ bad:
{
if (issuer == i)
{
-print_name(STDout, issuer=,
+print_name(STDout, issuer= ,
X509_get_issuer_name(x), nmflag);
}
else if (subject == i)
{
-print_name(STDout, subject=,
+print_name(STDout, subject= ,
X509_get_subject_name(x), nmflag);
}
else if (serial == i)
[no subject]
???:-D __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
-- ?? Nokia ?? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: The new subject hash algorithm
On Mon, Apr 22, 2013, Krzysztof Benedyczak wrote: Hi Openssl Developers, Since openssl 1.0.0 a new subject hash is used, i.e. the output of the openssl x509 -subject_hash ... has changed. The old one was quite easy to decipher and commonly known (part of the MD5 hash of the bin form of the subject name). Now AFAIU MD5 has been changed do SHA1, but it seems that there are also other modifications (some normalization? or?). Is it possible to get a precise information how openssl generate the the aforementioned subject hash? I can try to infer it from source of course, but having an algorithm description would be of great help. I was trying to find some information on the topic but no luck. The reason for the question is that in Java software I need to support openssl-like certificates trust store. It's a bit complex and you need to be able to decode and reencode the Name structure to duplicate this. The function x509_name_canon performs the reencoding this is in crypto/asn1/x_name.c: /* This function generates the canonical encoding of the Name structure. * In it all strings are converted to UTF8, leading, trailing and * multiple spaces collapsed, converted to lower case and the leading * SEQUENCE header removed. * This encoding is then used to perform the hash using SHA1 in a similar way to the old algorithm (see X509_NAME_hash function in crypto/x509/x509_cmp.c). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: The new subject hash algorithm
Hi, W dniu 24.04.2013 17:36, Dr. Stephen Henson pisze: On Mon, Apr 22, 2013, Krzysztof Benedyczak wrote: Hi Openssl Developers, Since openssl 1.0.0 a new subject hash is used, i.e. the output of the openssl x509 -subject_hash ... has changed. The old one was quite easy to decipher and commonly known (part of the MD5 hash of the bin form of the subject name). Now AFAIU MD5 has been changed do SHA1, but it seems that there are also other modifications (some normalization? or?). Is it possible to get a precise information how openssl generate the the aforementioned subject hash? I can try to infer it from source of course, but having an algorithm description would be of great help. I was trying to find some information on the topic but no luck. The reason for the question is that in Java software I need to support openssl-like certificates trust store. It's a bit complex and you need to be able to decode and reencode the Name structure to duplicate this. The function x509_name_canon performs the reencoding this is in crypto/asn1/x_name.c: /* This function generates the canonical encoding of the Name structure. * In it all strings are converted to UTF8, leading, trailing and * multiple spaces collapsed, converted to lower case and the leading * SEQUENCE header removed. * This encoding is then used to perform the hash using SHA1 in a similar way to the old algorithm (see X509_NAME_hash function in crypto/x509/x509_cmp.c). Thanks a lot for the answer. I've tried it on a simple DN and I was able to reproduce the same hash as is outputted by Openssl. However I have some general doubts regarding the algorithm: -) what about multi-valued RDNs? According to RFC their order is irrelevant. Do you somehow sort them for the c19 form? -) what is the definition of the 'string' above? TeletexString, PrintableString, UTF8String, BMPString? More or less? Thanks again, Krzysztof __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
The new subject hash algorithm
Hi Openssl Developers, Since openssl 1.0.0 a new subject hash is used, i.e. the output of the openssl x509 -subject_hash ... has changed. The old one was quite easy to decipher and commonly known (part of the MD5 hash of the bin form of the subject name). Now AFAIU MD5 has been changed do SHA1, but it seems that there are also other modifications (some normalization? or?). Is it possible to get a precise information how openssl generate the the aforementioned subject hash? I can try to infer it from source of course, but having an algorithm description would be of great help. I was trying to find some information on the topic but no luck. The reason for the question is that in Java software I need to support openssl-like certificates trust store. Thanks and best regards, Krzysztof __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
:o*@nn-idol*::D __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
:o*@nn-idol*::D __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: subject field issue in openssl certificate
From: owner-openssl-us...@openssl.org On Behalf Of Indtiny s Sent: Sunday, 16 December, 2012 11:04 This is not a -dev question. I am using root certiciate which is there in DER format at client , to verify the peer . When I execute my cCURL clinet code I get the below error . 223: SSL: couldn't get X509-subject! curl_easy_perform() failed: SSL connect error error no is 35 . I viewed the root certiciate using tool , I could see the subject field in the ceritificate . It is very unlikely curl is looking at the subject in the root (CA) cert; that is not relevant to anything it is doing. Almost certainly it is looking at the subject in the server (EE) cert, which could be using SubjAltNames and leaving Subject empty. Try commandline openssl s_client to your hostport and it will dump the server cert. Capture that to a file and display with openssl x509 -noout -text, or another tool like MS certmgr. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: SSL closing connection if the certs subject empty with curl client
From: owner-openssl-...@openssl.org On Behalf Of Indtiny s Sent: Thursday, 11 October, 2012 01:20 This is not a bug and doesn't really belong on -dev . I have converted my certificates which are in DER form to PEM using below openssl command (because curl wants that certificates to be in PEM format) openssl x509 -in root.x509 -inform DER -out root.crt -outform PEM If that filename is accurate and this is a root cert file, and is being used as/in your truststore, it's not just curl that wants PEM format, it's openssl. (For many things openssl supports both PEM and DER formats and sometimes others, but its standard truststore methods support only PEM.) And try to excute the curl client with error buffer set (it will save the errors which will thrown by ssl) , I get the below error while doing 223: SSL: couldn't get X509-subject! curl_easy_perform() failed: SSL connect error error no is 35 . I checked my cert with openssl x509 -in root.crt -inform PEM -noout -text and it shows that certificate does not have subject . Now is it mandatory to have the certificate with subject .. A *CA* certificate (root or chain) yes. RFC 5280 4.1.2.6 et al. Officially an *entity* cert can use SAN and empty Subject. (You can't actually omit Subject from the ASN.1, only make it an empty sequence -- no RDN elements.) I haven't tested if this works with openssl, although I see no logical reason it shouldn't. How to disable this at openssl part ..? OpenSSL chains only by child.issuer = parent.subject, although in principle AKI can be used instead. If you did disable this, you would have to accept all servers (or other signers) including the fraudulent ones, and you almost might as well just drop SSL (or other crypto) and use cleartext. (You do expose your sensitive data only to one crook at a time, if that's a benefit.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2873] [Bug] -noemailDN only affects Subject DN
When the -noemailDN flag is used with the openssl ca command, the email address is only removed from the Subject DN, but not the Issuer DN. This leaves self-signed CA certs created with this flag unverifiable, because the DNs do not match. -- Stefan H. Holek ste...@epy.co.at __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
On the FIPS 140 web page under Current Status it indicates that The current best estimate for final formal award of a FIPS 140-2 validation certificate is February 2012. Can someone confirm for me that windows 7 will be included?
[no subject]
The current openssl-1.0.1-stable-SNAP-2021 and the last 6 or so previous versions fails with the following on Microsoft Windows: ssltest.c link /nologo /subsystem:console /opt:ref /debug /out:out32\ssltest.exe @ C:\DOCUME~1\zkrr01\LOCALS~1\Temp\nne04256. ssleay32.lib(t1_enc.obj) : error LNK2001: unresolved external symbol _bcmp out32\ssltest.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. In addition, the following warnings are received: C:\work\openssl-1.0.1-stable-SNAP-2021perl util\mkdef.pl 32 libeay 1ms\libeay32.def WARNING: mkdef.pl doesn't know the following algorithms: NEXTPROTONEG C:\work\openssl-1.0.1-stable-SNAP-2021perl util\mkdef.pl 32 ssleay 1ms\ssleay32.def WARNING: mkdef.pl doesn't know the following algorithms: NEXTPROTONEG Warning: SSL_CTX_set_next_proto_select_cb does not have a number assigned Warning: SSL_CTX_set_next_protos_advertised_cb does not have a number assigned Warning: SSL_export_keying_material does not have a number assigned Warning: SSL_get0_next_proto_negotiated does not have a number assigned Warning: SSL_select_next_proto does not have a number assigned InterSoft International, Inc. Voice: 888-823-1541 Fax: 866-701-1260 http://www.netterm.com http://www.securenetterm.com
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
On 09/11/2011 12:12 AM, Erwann ABALEA wrote:
Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit:
According to rfc1779, the key STREET in the subject name should be capitalized.
obj_dat.h specifies it as a lower-cased street.
This is incorrect and breaks when OpenSSL is used to parse in rfc1779-compliant
distinguished names generated by external parties.
The solution is to upper-case it to STREET, just like C, CN, etc.
The street attribute type (OID 2.5.3.9) is not defined by RFC1779.
This RFC doesn't state that those tokens are case sensitive (you could
even use cn instead of CN).
This RFC is defective at least in one aspect: the following names are
not considered equal:
CN=James Bond, O=MI6, C=UK
CN=James \ Bond, O=MI6, C=UK
CN=\ \ jAmeS bonD, O=MI6, C=UK
these examples are equal, following X.520 rules.
Hm,
OID 2.5.3.9 is id-at-streetAddress*OBJECT IDENTIFIER* ::= {id-at
http://www.itu.int/ITU-T/formal-language/itu-t/x/x501/2008/UsefulDefinitions.html#UsefulDefinitions.id-at
9}
streetAddressATTRIBUTE
http://www.itu.int/ITU-T/formal-language/itu-t/x/x501/2008/InformationFramework.html#InformationFramework.ATTRIBUTE
::= {
WITH SYNTAXUnboundedDirectoryString
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.UnboundedDirectoryString
EQUALITY MATCHING RULEcaseIgnoreMatch
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.caseIgnoreMatch
SUBSTRINGS MATCHING RULEcaseIgnoreSubstringsMatch
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.caseIgnoreSubstringsMatch
IDid-at-streetAddress
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.id-at-streetAddress
}
In 1779
CN CommonName
L LocalityName
ST StateOrProvinceName
O OrganizationName
OU OrganizationalUnitName
C CountryName
STREET StreetAddress
rfc 4514 has
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
in objects.txt
X509 3: CN : commonName
X509 6: C: countryName
X509 7: L: localityName
X509 8: ST: stateOrProvinceName
X509 9: street: streetAddress
X509 10: O: organizationName
X509 11: OU: organizationalUnitName
IMO should be STREET
(but existing req etc config files should become broken)
the rfc doesn't treat equality or matching.
the rfc describes a textual representation of an encoded name.
not any kind of canonical or distinguished form.
btw your examples seem wrong to me, a space cannot escaped by \
as far as I understand rfc 1779
string ::= *(stringchar |pair )
| '' *(stringchar |special |pair ) ''
| #hex
special ::= , | = |CR | + | |
| # | ;
pair ::= \ (special | \ | '')
stringchar ::= any character exceptspecial or \ or ''
rfc 4514 has ' ', '', '#', '+', ',', ';', '', '=','', or '\'
The textual representations
CN= jAmes bonD
CN=James Bond
designate different encodings that match, i.e.
only one could be in a directory.
have fun
Peter Sylvester
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Hodie III Id. Sep. MMXI, Peter Sylvester scripsit:
On 09/11/2011 12:12 AM, Erwann ABALEA wrote:
Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit:
According to rfc1779, the key STREET in the subject name should be
capitalized.
obj_dat.h specifies it as a lower-cased street.
This is incorrect and breaks when OpenSSL is used to parse in
rfc1779-compliant distinguished names generated by external parties.
The solution is to upper-case it to STREET, just like C, CN, etc.
The street attribute type (OID 2.5.3.9) is not defined by RFC1779.
This RFC doesn't state that those tokens are case sensitive (you could
even use cn instead of CN).
This RFC is defective at least in one aspect: the following names are
not considered equal:
CN=James Bond, O=MI6, C=UK
CN=James \ Bond, O=MI6, C=UK
CN=\ \ jAmeS bonD, O=MI6, C=UK
these examples are equal, following X.520 rules.
Hm,
OID 2.5.3.9 is id-at-streetAddress OBJECT IDENTIFIER ::= {[1]id-at 9}
streetAddress [2]ATTRIBUTE ::= {
WITH SYNTAX [3]UnboundedDirectoryString
EQUALITY MATCHING RULE[4]caseIgnoreMatch
SUBSTRINGS MATCHING RULE [5]caseIgnoreSubstringsMatch
ID[6]id-at-streetAddress
}
In 1779
CN CommonName
L LocalityName
ST StateOrProvinceName
O OrganizationName
OU OrganizationalUnitName
C CountryName
STREET StreetAddress
rfc 4514 has
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
in objects.txt
X509 3 : CN : commonName
X509 6 : C : countryName
X509 7 : L : localityName
X509 8 : ST : stateOrProvinceName
X509 9 : street : streetAddress
X509 10 : O : organizationName
X509 11 : OU : organizationalUnitName
IMO should be STREET
(but existing req etc config files should become broken)
the rfc doesn't treat equality or matching.
the rfc describes a textual representation of an encoded name.
not any kind of canonical or distinguished form.
If the OP is concerned by a mismatch between street and STREET
then I guess his question concerns matching strings.
The OP also complains that OpenSSL has a problem parsing
RFC1779-compliant DNs. In fact, OpenSSL doesn't parse RFC1779 names.
It has its own format.
btw your examples seem wrong to me, a space cannot escaped by \
as far as I understand rfc 1779
I could have used quotes, yes, but escaping is valid (yet ugly).
-
The quoting mechanism is used for the following cases:
o Strings containing ,, +, = or , CR, ,
, #, or ;.
o Strings with leading or trailing spaces
o Strings containing consecutive spaces
-
Quoting is defined as prefixing the character with a \, or enclosing
the whole string in a pair, or both (is the string also contains
characters).
rfc 4514 has ' ', '', '#', '+', ',', ';', '', '=', '', or '\'
And RFC4519 names the attribute 'street', and all others in lowercase.
The textual representations
CN= jAmes bonD
CN=James Bond
designate different encodings that match, i.e.
only one could be in a directory.
Yes, as cn=James Bond, i.e. the case of the directory attribute name
is not important.
Test it an LDAPv3-compliant LDAP server, and you'll be able to use
both forms (lower and upper case) for the directory attributes. You
may even be able to use the OID form. Same with the certificateMatch
filter, if your LDAP server supports it.
--
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit: According to rfc1779, the key STREET in the subject name should be capitalized. obj_dat.h specifies it as a lower-cased street. This is incorrect and breaks when OpenSSL is used to parse in rfc1779-compliant distinguished names generated by external parties. The solution is to upper-case it to STREET, just like C, CN, etc. The street attribute type (OID 2.5.3.9) is not defined by RFC1779. This RFC doesn't state that those tokens are case sensitive (you could even use cn instead of CN). This RFC is defective at least in one aspect: the following names are not considered equal: CN=James Bond, O=MI6, C=UK CN=James \ Bond, O=MI6, C=UK CN=\ \ jAmeS bonD, O=MI6, C=UK these examples are equal, following X.520 rules. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
Hi everybody I am trying to do some time measurement in openssl when the apache is running, I would like to plug in the small code in openssl and do some print out(when apache runs)and mesure the tick. Can anybody help me to do the printf in openssl? Thanks
[no subject]
Hi, I am experiencing some weird problem. After running for few seconds, server sends some malformed SSL packets to Client. This problem is mainly seen on lower bandwidth. If i increase the bandwidth then this problem is not seen. Can anybody suggests me how to resolve this problem. Any workaround is also appreciated. Thanks, Sandeep Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
[openssl.org #2136] Add display of old-style (MD5) subject/issuer hash to x509 command
This is an enhancement request that addresses an incompatibility
introduced with the new SHA1-based hashing of the subject/issuer name
defined in openssl 1.0.0. The necessary patches based on openssl
1.0.0-beta4 are attached.
Reason for the request:
The change forces sites, that distribute information, e.g. links, based
on the subject/issuer hash to sites using either 0.9.x or 1.x.x versions
of openssl, to install both of these versions in order to be able to
generate and display the hashes required for the 2 versions.
Since the basic functions required for the generation of both hash types
are anyhow present in openssl version 1.0.0+ only the integration of the
old-style (MD5 based) hash in the x509 command as an additional display
option for both the subject and the issuer hash is missing. The attached
patches for apps/x509.c and crypto/x509/x509_cmp.c provide the necessary
additions.
Please add the requested feature to the final 1.0.0 release.
Best regards
Willy Weisz
--
---
Willy Weisz
European Centre for Parallel Computing at Vienna (VCPC)
Computational Science Center
Nordbergstrasse 15/C312
A-1090 Wien
Tel: (+43 1) 4277 - 39424 Fax: (+43 1) 4277 - 9394
Mobile: +43 699 10109546e-mail: we...@vcpc.univie.ac.a
--- apps/x509.c.orig2009-10-18 16:42:26.0 +0200
+++ apps/x509.c 2010-01-10 01:20:45.0 +0100
@@ -99,7 +99,13 @@
-passin arg - private key password source\n,
-serial - print serial number value\n,
-subject_hash - print subject hash value\n,
+#ifndef OPENSSL_NO_MD5
+ -subject_hash_old - print old-style (MD5) subject hash value\n,
+#endif
-issuer_hash- print issuer hash value\n,
+#ifndef OPENSSL_NO_MD5
+ -issuer_hash_old- print old-style (MD5) issuer hash value\n,
+#endif
-hash - synonym for -subject_hash\n,
-subject- print subject DN\n,
-issuer - print issuer DN\n,
@@ -179,6 +185,9 @@
int text=0,serial=0,subject=0,issuer=0,startdate=0,enddate=0;
int next_serial=0;
int subject_hash=0,issuer_hash=0,ocspid=0;
+#ifndef OPENSSL_NO_MD5
+ int subject_hash_old=0,issuer_hash_old=0;
+#endif
int noout=0,sign_flag=0,CA_flag=0,CA_createserial=0,email=0;
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
@@ -397,8 +406,16 @@
else if (strcmp(*argv,-hash) == 0
|| strcmp(*argv,-subject_hash) == 0)
subject_hash= ++num;
+#ifndef OPENSSL_NO_MD5
+ else if (strcmp(*argv,-subject_hash_old) == 0)
+ subject_hash_old= ++num;
+#endif
else if (strcmp(*argv,-issuer_hash) == 0)
issuer_hash= ++num;
+#ifndef OPENSSL_NO_MD5
+ else if (strcmp(*argv,-issuer_hash_old) == 0)
+ issuer_hash_old= ++num;
+#endif
else if (strcmp(*argv,-subject) == 0)
subject= ++num;
else if (strcmp(*argv,-issuer) == 0)
@@ -759,10 +776,22 @@
{
BIO_printf(STDout,%08lx\n,X509_subject_name_hash(x));
}
+#ifndef OPENSSL_NO_MD5
+ else if (subject_hash_old == i)
+ {
+
BIO_printf(STDout,%08lx\n,X509_subject_name_hash_old(x));
+ }
+#endif
else if (issuer_hash == i)
{
BIO_printf(STDout,%08lx\n,X509_issuer_name_hash(x));
}
+#ifndef OPENSSL_NO_MD5
+ else if (issuer_hash_old == i)
+ {
+
BIO_printf(STDout,%08lx\n,X509_issuer_name_hash_old(x));
+ }
+#endif
else if (pprint == i)
{
X509_PURPOSE *ptmp;
--- crypto/x509/x509_cmp.c.orig 2009-05-30 20:10:59.0 +0200
+++ crypto/x509/x509_cmp.c 2010-01-10 01:21:45.0 +0100
@@ -133,6 +133,13 @@
return(X509_NAME_hash(x-cert_info-issuer));
}
+#ifndef OPENSSL_NO_MD5
+unsigned long X509_issuer_name_hash_old(X509 *x)
+ {
+ return(X509_NAME_hash_old(x-cert_info-issuer));
+ }
+#endif
+
X509_NAME *X509_get_subject_name(X509 *a)
{
return(a-cert_info-subject);
@@ -148,6 +155,13 @@
return(X509_NAME_hash(x-cert_info-subject));
}
+#ifndef OPENSSL_NO_MD5
+unsigned long X509_subject_name_hash_old(X509 *x)
+ {
+ return(X509_NAME_hash_old(x-cert_info-subject));
+ }
+#endif
+
#ifndef OPENSSL_NO_SHA
/* Compare two certificates: they must be identical for
* this to work. NB: Although cmp operations
[no subject]
Hi what means: Error Loading extension section v3_ca I received this error when I type: openssl x509 -req -in rootreq.pem -sha1 -extfile myconf.cnf -extensions v3_ca -signkey rootkey.pem -out rootcert.pem --
PKIX Design Survey: ECC Public Keys in Subject Public Key Info
Looking for input on the two questions at the end of this message. ECC Design Team Survey Background The PKIX WG has been presented with two different proposals for the specification of ECC public keys in the subject public key info field of X.509 certificates. Proposal #1: A current PKIX ID (http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-03.txt) based on the ANSI X9.62-2005 standard specifies a structured a public key info field with (up to) four components: * the algorithm family (i.e., ECC), * the public key, * an explicit or implicit specification of ECC parameters (implicit specifications include inheritance from the CA and OIDs that specify a named curve), and * an optional set of OIDs specifying the supported modes (e.g., 1 pass DH or full MQV). The set of supported modes is very granular, and includes ancillary cryptographic functions. For signature algorithms, the mode specifies supported hash algorithms. For example, separate OIDs are defined for ECDSA with SHA-1, SHA-256, SHA-384, and SHA-512.For key agreement algorithms, the mode specifies the key establishment scheme (e.g., MQV one pass mode vs. MQV full mode) as well as the key derivation function (kdf). Proposal #2: Two PKIX specifications, RFCs 3279 and 4055, currently define the specification of RSA, DSA, Diffie-Hellman, and ECC public keys. In these specifications, the public key info field has (up to) three components: * The algorithm (e.g., RSA or ECC); * The public key; and * An optional set of parameters (parameters are omitted if they are inherited from the issuer, or where not required by the algorithm as in the case of the RSA). Where public keys are compatible with different classes of operations, restrictions are imposed using the key usage extension. When applied to ECC, this approach would provide less specific restrictions than the ANSI-based proposal. For instance, the key usage extension permits the issuer to restrict use of an ECC key to digital signatures, but would not explicitly limit use to ECDSA or specify allowable hash algorithms. As a second example, a key usage extension asserting only keyAgreement could be used to limit the use of the public key to ECDH and ECMQV, but could not be used to impose further restrictions (e.g., MQV but not Diffie-Hellman, or full MQV mode but not one pass.) The Design Team was formed to review the tradeoffs between these two approaches. As an initial step, the Design Team developed a set of design criteria, below. Note that the design team did not prioritize these criteria. The design criteria are: (1) The specified solution must support security-relevant constraints sufficient to protect the corresponding private key. In particular, the issuer must be able to prevent use of the public key in undesirable combinations of algorithms or modes. (For example, could the use of the key in both signature and key agreement modes place the private key at risk? Alternatively, could use of the key in both Diffie-Hellman and MQV modes place the private key at risk?) (2) The specified solution must promote interopability. Specific considerations include: * How should implementations of RFC 3279, the future PKIX specification, and the ANSI specification interact? * What is the impact on current and emerging protocol specifications? For example, would the resulting certificates be usable in TLS or S/MIME? * Would existing certificates specified using this solution be applicable to new or updated protocols? * Should common limitations in cryptographic support (e.g., DH but not MQV) be accommodated in the certificate format or should these limitations be discovered in the application protocols? * What is the impact on APIs? (3) The specified solution should support cryptographic agility. The cryptographic suite is evolving over time, with the introduction of new algorithms and changes in the perception of cryptographic strength. For example, new hash algorithms will probably be introduced during the life of this specification. The specification must not create an environment where certificates must be reissued to accommodate every change in the cryptographic suite. (4) The specified solution should not require revalidation of products that have been certified under FIPS 140. If the specified solution requires changes within the cryptographic module boundary, the time to market for compliant implementations will be adversely impacted. (5) The specified solution should not be unduly complex. The most common assertions should be specified in a straightforward manner. Survey Questions (1) Are there any missing important design criteria? (2) Which proposal do you prefer? Please explain your preference based on the design criteria, including any additional criteria you have identified. __ OpenSSL Project http://www.openssl.org
[no subject]
Hi, I've just tried compiling OpenSSL-0.9.8a for HPPA64 architecture (using gcc-4.1) and 'make test' ends with ... ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest *** Termination signal 139 Stop. *** Error exit code 1 Stop. Any known remedy? E.g. compiling specific files with lower optimiation level? TIA, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[no subject]
Hi Richard, Thanks for taking a look at this. [guest - Thu Oct 6 11:55:10 2005]: This stops our engine working with the openssl application (as it registers a lock debugging callback) and Apache 2.x (and other apps too no doubt) That's because those applications don't set up callbacks for the dynamic locks. The correct thing to do is to talk with the application authors and tell them that there are new requirements to make engines work. Unfortunately we do not have relationships with all of the application developers for the applications that our customers use, so this is not possible. We shall certainly apply pressure in this direction where we can. On that note, is there a plan to update the apps/openssl application to not use the static lock callback for lock debugging? or is there something else that we could do instead to allow our engine to work with static locks? It seems that the dynamic locks are rarely used. Yes, it's true, they are rarely use... currently. However, I really would encourage people to use them more, as they are a bit more flexible than the static locks. Ideally, OpenSSL should probably move to dynamic locks entirely, which would make maintainance quite a bit easier. The dynamic locks are clearly a much better solution and removing them from openssl will force all applications to move , which would be a good thing in the long run. Is there a plan to do this for any specific future release? Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? It seems a bit unfair on the end users who need hardware support for openssl to keep the interface, so the apps don't realise that they need to change, but to remove the engine support from these apps. I appreciate that the hack for our static lock was not pleasant, but it is no less pleasant than all the other static locks. Are you sure we can't persuade you to put it back in until all static locks are removed? By the way, do you have an nCipher HSM for interop testing? Thanks again -john -- John Hartley nCipher Ltd http://www.ncipher.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[no subject]
Dear Developers, I am interested in plugging in my own implementations of the crypto algorithm AES(rijndael) into the open ssl source code.Later on I would also like to do the same for the RSA algo and the symmetric key generator(AES based PRBG as per FIPS stds). Please guide me how to go about doing this.As of now,I do not have any knowledge of the working or the designof openssl source code. Thanking you Yahoo! India Matrimony: Find your partner online.
[openssl.org #1060] [Bug Report] can't build user/issuer certificate chain with different asn1 types in issuer/subject
[EMAIL PROTECTED] - Fri May 6 19:20:48 2005]: Hello, I have noticed a problem while using TC Trustcenter certificates with OpenSSL. The encoding of the 'Subject' in the issuer cert contrains 'T61String' elements while the user cert issued by that sub-CA contains only 'Printablestring' in the 'Issuer' field. Based on that difference in types, OpenSSL is unable to a) find the issuer cert in the certstore because the hashes are different and b) locate the certificate in the stack using sk_find after I placed the issuer cert in the store twice, with both names/hashes. Neither 0.9.7e nord 0.9.8 are able to build the cert chain. I did some debugging with 0.9.7e, which lead me to the conclusions stated above. I rate this behaviour as a bug because the connection between two certs shouldn't be based on the way a string is encoded but on it's value. I'm working on a temp workaround for our specific case but it's by no means a fix for the problem. Almost all certificates not only keeps the same string type but also the same encoding. Doing otherwise would break quite a lot of software. This also violates various standards. For example in RFC3280. The DN comparision algorithm states: (a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings; Later on it also states: CAs MUST encode the distinguished name in the subject field of a CA certificate identically to the distinguished name in the issuer field in certificates issued by that CA. Nevertheless newer versions of OpenSSL should handle this situation but not for the directory (CApath) based lookup. If the certificate is added in a file based manner (CAfile) or directly it should be OK. Directory based lookup will be supported at some point but it would break existing hashes. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1060] [Bug Report] can't build user/issuer certificate chain with different asn1 types in issuer/subject
Hello, I have noticed a problem while using TC Trustcenter certificates with OpenSSL. The encoding of the 'Subject' in the issuer cert contrains 'T61String' elements while the user cert issued by that sub-CA contains only 'Printablestring' in the 'Issuer' field. Based on that difference in types, OpenSSL is unable to a) find the issuer cert in the certstore because the hashes are different and b) locate the certificate in the stack using sk_find after I placed the issuer cert in the store twice, with both names/hashes. Neither 0.9.7e nord 0.9.8 are able to build the cert chain. I did some debugging with 0.9.7e, which lead me to the conclusions stated above. I rate this behaviour as a bug because the connection between two certs shouldn't be based on the way a string is encoded but on it's value. I'm working on a temp workaround for our specific case but it's by no means a fix for the problem. Best Regards, Robert Esterer __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[no subject]
Here is what i am
trying to do...
Config file has
these lines:
[ CA_default
]
..
x509_extensions = usr_cert
[ usr_cert
]
basicConstraints=CA:FALSE
keyUsage =
digitalSignature, keyEnciphermentsubjectKeyIdentifier=hashauthorityKeyIdentifier=keyid,issuer:always
#
Certificate PoliciescertificatePolicies = ia5org,@capol
[ capol
]
##
Generic Certificate
Policies#[capol]policyIdentifier=avayaCPSCPS.1=https://www.foo.com;
[EMAIL PROTECTED]
[capoln]explicitText="Please visit http://www.foo.com for details.";organization="Product
CA"noticeNumbers=1
I am
using the following to read
// Read
config fileint readSSLConfigFile(char
*pSSLConfigFile){
long errorline = -1;
// Read the
config file to set up the necessary
extension pConfig =
NCONF_new(NULL);
if(NCONF_load(pConfig, pSSLConfigFile, errorline)
0)
{
if(errorline =
0)
{
// Log message Error loading config
file
}
else
{
// Log message Error on line %ld of config file %s:,
errorline
}
return FAILURE;
}
// load
openssl builtin modules
OPENSSL_load_builtin_modules();
// load
config
if(CONF_modules_load(pConfig, NULL, 0) =
0)
{
// log error configuring
OpenSSL
return FAILURE;
}
// get the
section we will need, the
extensions if((section =
NCONF_get_string(pConfig, BASE_SECTION, DEFAULT_CA)) ==
NULL)
{
// Log config base section lookup
failed
return FAILURE;
}
// Now we
need to get the extension section
pGlobalExtensions = NULL;
pGlobalExtensions = NCONF_get_string(pConfig, section,
V3_EXTENSIONS);
if(!pGlobalExtensions)
{
// Log message failed to read global config
file
return FAILURE;
}
else
{
X509V3_CTX
ctx;
X509V3_set_ctx_test(ctx);
X509V3_set_nconf(ctx,
pConfig);
if(!X509V3_EXT_add_nconf(pConfig, ctx, pGlobalExtensions,
NULL))
{
// Log message Failed to load extension section %s
pGlobalExtensions
return
FAILURE;
}
} return
SUCCESS;}
It fails at X509V3_EXT_add_nconf. when i comment out the line
containing the policy identifier (@capol)
it works fine.
am i missing something???
satish
Your e-mail to nedelcho.stanev@atlanticsky.com (Subject: [openssl.org #820] openssl 0.9.7c bug )
Hello, You e-mail address ([EMAIL PROTECTED]) has NOT been validated, possibly because the code you entered was incorrect. Your message (Subject: [openssl.org #820] openssl 0.9.7c bug ) has therefore not been delivered to [EMAIL PROTECTED] Please, re-enter it. If in the meanwhile you have deleted the original address verification e-mail, just send another mail to [EMAIL PROTECTED] to receive a new challenge and enter there the new code. Thank you! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
Dr. Stephen Henson wrote: On Mon, Nov 24, 2003, Michael Bell wrote: some people ask me how to create the following subject for certificates: cn=abc + serialNumber=123,o=company,c=de It is no problem to insert this subject to the -subj option of openssl ca but the sourcecode looks like OpenSSL ca uses abc + serialNumber=123 as value. Is this correct and if yes is there a way to issue certificates with mutlivalued attributes in RDNs? Yes but you need OpenSSL 0.9.8-dev for this. It doesn't (yet) work with -subj but if you use the config file for 'req' and make the first character of a DN component '+' it should create a multivalued RDN correctly. -subj in ca.c is important for me. So I start reading the code. I dug in req.c and it looks for me like mval signals as the last argument to X509_NAME_add_entry_by_NID that this is not a new RDN only an addition to the last RDN. Does this be correct? If yes then I start fixing -subj for ca.c or better I'm fixing do_subject which is used by req.c too. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
On Tue, Nov 25, 2003, Michael Bell wrote: -subj in ca.c is important for me. So I start reading the code. I dug in req.c and it looks for me like mval signals as the last argument to X509_NAME_add_entry_by_NID that this is not a new RDN only an addition to the last RDN. Does this be correct? Yes that's correct. If yes then I start fixing -subj for ca.c or better I'm fixing do_subject which is used by req.c too. There's possibly a problem in that it would change the meaning of the '+' character which might break existing use of -subj or even permit some malicious use. So I'd suggest that any new behaviour should only be enabled with a command line swicth. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
Dr. Stephen Henson wrote: There's possibly a problem in that it would change the meaning of the '+' character which might break existing use of -subj or even permit some malicious use. So I'd suggest that any new behaviour should only be enabled with a command line swicth. Ok, taken. I created a patch and will put it into the request tracker. It uses a new option -multivalue-rdn to activate the new code. another problem is the output like you mentioned. -nameopt oneline works but -nameopt rfc2253 fails. rfc2253 escapes a blank but perhaps I send the blank to OpenSSL by myself - so no real problem. This is not wrong but it is senseless. oneline --- C = DE, O = Humboldt-Universitaet zu Berlin, OU = Internet, serialNumber = 123456 + CN = ABC XYZ , serialNumber = 30 rfc2253 --- serialNumber=30,CN=ABC XYZ \ +serialNumber=123456,OU=Internet,O=Humboldt-Universitaet zu Berlin,C=DE Thanks for your help Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
On Tue, Nov 25, 2003, Michael Bell wrote: another problem is the output like you mentioned. -nameopt oneline works but -nameopt rfc2253 fails. rfc2253 escapes a blank but perhaps I send the blank to OpenSSL by myself - so no real problem. This is not wrong but it is senseless. Senseless it may be but it is a requirement of RFC2253. In 2.4 is clearly states that if a space occurs at the end of a string then it must be escaped. Who am I to argue? :-) Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
subject design for certificates
Hi, some people ask me how to create the following subject for certificates: cn=abc + serialNumber=123,o=company,c=de It is no problem to insert this subject to the -subj option of openssl ca but the sourcecode looks like OpenSSL ca uses abc + serialNumber=123 as value. Is this correct and if yes is there a way to issue certificates with mutlivalued attributes in RDNs? Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
On Mon, Nov 24, 2003, Michael Bell wrote: Hi, some people ask me how to create the following subject for certificates: cn=abc + serialNumber=123,o=company,c=de It is no problem to insert this subject to the -subj option of openssl ca but the sourcecode looks like OpenSSL ca uses abc + serialNumber=123 as value. Is this correct and if yes is there a way to issue certificates with mutlivalued attributes in RDNs? Yes but you need OpenSSL 0.9.8-dev for this. It doesn't (yet) work with -subj but if you use the config file for 'req' and make the first character of a DN component '+' it should create a multivalued RDN correctly. The default (alas broken) DN print options don't display this properly. If you use some other option like -nameopt oneline then it should be displayed approptiately. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
Dear friends, I want to use Openssl on MVS operating system on S/390. I would appreciate if any one provide links/pointers to this port. thanks in Advance, Antonio Dima __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
Hi all, I just try to recompile my openssl applications with the 0.9.7c and the PKCS12_decrypt_d2i function no longer exist. I can use my own decrypt/d2i function but I would prefer to use what OpenSSL provides as a replacement, if any. Any idea? Pierre De Boeck Sr System Engineer Cipherquest email:[EMAIL PROTECTED] BEGIN:VCARD VERSION:2.1 N:De Boeck;Pierre FN:Cipherquest ORG:Cipherquest TITLE:Sr System Engineer TEL;WORK;VOICE:+352 (264) 78201 TEL;HOME;VOICE:+32 2 759 44 96 TEL;CELL;VOICE:+32 0479846599 TEL;WORK;FAX:+352 (264) 78202 ADR;WORK:;;Rue de l'eau 22;Luxembourg;;1449;Luxembourg LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Rue de l'eau 22=0D=0ALuxembourg 1449=0D=0ALuxembourg KEY;X509;ENCODING=BASE64: MIIHFDCCBfygAwIBAgIBDjANBgkqhkiG9w0BAQUFADCBnTETMBEGCgmSJomT8ixkARkTA2Nv bTEhMB8GCgmSJomT8ixkARkTEW1pc3Npb25jcml0aWNhbGl0MRkwFwYDVQQKExBNaXNzaW9u IENyaXRpY2FsMQ4wDAYDVQQLEwVVc2VyczE4MDYGA1UEAxMvTWlzc2lvbiBDcml0aWNhbCBT QSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgVXNlcnMwHhcNMDIwNTMxMTIzODQ5WhcNMDUwNTMw MTIzODQ5WjCBmzETMBEGCgmSJomT8ixkARkTA2NvbTEhMB8GCgmSJomT8ixkARkTEW1pc3Np b25jcml0aWNhbGl0MRkwFwYDVQQKExBNaXNzaW9uIENyaXRpY2FsMQ4wDAYDVQQLEwVVc2Vy czE2MBwGCgmSJomT8ixkAQETDnBpZXJyZS5kZWJvZWNrMBYGA1UEAxMPUGllcnJlIERlIEJv ZWNrMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOM/j+er1XEuDjwTzM5DrE/pu1PMH1ObaZCY VDwzAuUVg5wxRFqK4vYbQkRoP3mbUDOlE9/LvZqBNh0WJkheFTUCAwEAAaOCBCUwggQhMBEG CWCGSAGG+EIBAQQEAwIFoDAsBglghkgBhvhCAQIEHxYdaHR0cDovL3d3dy5taXNjcml0LmJl L0NsYXZpcy8wOgYJYIZIAYb4QgEDBC0WK2RyQ2VydFNlcnZlci9kckNBL3Jldm9rZS5hc3A/ SWRDYT00JnNlcmlhbD0wOgYJYIZIAYb4QgEEBC0WK2RyQ2VydFNlcnZlci9kckNBL3Jldm9r ZS5hc3A/SWRDYT00JnNlcmlhbD0wOQYJYIZIAYb4QgEHBCwWKmRyQ2VydFNlcnZlci9kckNB L3JlbmV3LmFzcD9JZENhPTQmc2VyaWFsPTAyBglghkgBhvhCAQgEJRYjZHJDZXJ0U2VydmVy L2RyQ0EvcG9saWN5LmFzcD9JZENhPTQwLgYJYIZIAYb4QgENBCEWH2EgdXNlciBjZXJ0IGZv ciBQaWVycmUgRGUgQm9lY2swHQYDVR0OBBYEFPl9oN0hgQQpsBcvMqM1vtTmqa0EMC8GA1Ud EQQoMCaBJHBpZXJyZS5kZWJvZWNrQG1pc3Npb25jcml0aWNhbGl0LmNvbTALBgNVHQ8EBAMC BPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIHHBgNVHSMEgb8wgbyAFB3Gqkxo 8jPYniuQwaajND7lkzVJoYGgpIGdMIGaMRMwEQYKCZImiZPyLGQBGRMDY29tMSEwHwYKCZIm iZPyLGQBGRMRbWlzc2lvbmNyaXRpY2FsaXQxGTAXBgNVBAoTEE1pc3Npb24gQ3JpdGljYWwx CzAJBgNVBAsTAkNBMTgwNgYDVQQDEy9NaXNzaW9uIENyaXRpY2FsIFNBIFRydXN0IENlcnRp ZmljYXRlIEF1dGhvcml0eYIBAzBdBgNVHRIEVjBUgQ5wZGVAbWlzY3JpdC5iZYZCaHR0cDov L3d3dy5taXNjcml0LmJlL0NsYXZpcy9kckNlcnRTZXJ2ZXIvZHJDQS9ob21lcGFnZS5hc3A/ SWRDYT00MIHRBgNVHSAEgckwgcYwgcMGCisGAQQBolQBAQEwgbQwQwYIKwYBBQUHAgEWN2h0 dHA6Ly93d3cubWlzY3JpdC5iZS9DbGF2aXMvZHJDZXJ0U2VydmVyL2RyQ0EvQ1BTLmh0bWww bQYIKwYBBQUHAgIwYTAaFhBNaXNzaW9uIENyaXRpY2FsMAYCAQECAQQaQ3RoaXMgaXMgYW4g ZXhwZXJpbWVudGFsIGNlcnRpZmljYXRlIHBvbGljeSAoMS4zLjYuMS40LjEuNDQzNi4xLjEu MSkwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3d3dy5taXNjcml0LmJlL0NsYXZpcy9kckNl cnRTZXJ2ZXIvZHJDQS9jcmwuYXNwP0lkQ2E9NDANBgkqhkiG9w0BAQUFAAOCAQEAjAm35s2r c8R0M/wqhgrhNQCfO0V2dRN9shFf4X/lYvMJEZi0kWWafSg8XnBlt4H48GyfwYqSweQHanqU +uT1bf6WESqbSk7n3Dj5cwlWUUhyAeLkHBhlUu9b/IZWVUuUQ0ZpwbW+d6tIoyaA4mhNcMge v/uKsNmUnY+ft5hrEpTnipJkVl0Tx8HazdtDM5/a03FNqEq7rBR6Zibg5JwXH+OXT1qaGRfX HXNKR6sAJdZuf4DnnP4xwAqxViFOQhXdbEvN1kEJvCXmmVmLtmalSM7tjLbkbXIifSgHVz+F YHUTUDMvKo8CIOtp/rJJAUEZdnbUYLey7UMnZbPIA+siw7== KEY;X509;ENCODING=BASE64: MIIGxjCCBa6gAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnTETMBEGCgmSJomT8ixkARkTA2Nv bTEhMB8GCgmSJomT8ixkARkTEW1pc3Npb25jcml0aWNhbGl0MRkwFwYDVQQKExBNaXNzaW9u IENyaXRpY2FsMQ4wDAYDVQQLEwVVc2VyczE4MDYGA1UEAxMvTWlzc2lvbiBDcml0aWNhbCBT QSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgVXNlcnMwHhcNMDIwMTA4MTAzMTEyWhcNMDUwMTA3 MTAzMTEyWjB4MRkwFwYDVQQKExBNaXNzaW9uIENyaXRpY2FsMQ4wDAYDVQQLEwVVc2VyczFL MDEGCSqGSIb3DQEJARYkcGllcnJlLmRlYm9lY2tAbWlzc2lvbmNyaXRpY2FsaXQuY29tMBYG A1UEAxMPUGllcnJlIERlIEJvZWNrMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMunv/84LfjY mUf9ygS+oAAIfMoZQRLsYmVi1+KiDxW2yOi+REGP5A37/LAvMFjDXEZc9N82ihLHxH0aP1xK PJECAwEAAaOCA/swggP3MBEGCWCGSAGG+EIBAQQEAwIFoDAsBglghkgBhvhCAQIEHxYdaHR0 cDovL3d3dy5taXNjcml0LmJlL0NsYXZpcy8wOgYJYIZIAYb4QgEDBC0WK2RyQ2VydFNlcnZl ci9kckNBL3Jldm9rZS5hc3A/SWRDYT00JnNlcmlhbD0wOgYJYIZIAYb4QgEEBC0WK2RyQ2Vy dFNlcnZlci9kckNBL3Jldm9rZS5hc3A/SWRDYT00JnNlcmlhbD0wOQYJYIZIAYb4QgEHBCwW KmRyQ2VydFNlcnZlci9kckNBL3JlbmV3LmFzcD9JZENhPTQmc2VyaWFsPTAyBglghkgBhvhC AQgEJRYjZHJDZXJ0U2VydmVyL2RyQ0EvcG9saWN5LmFzcD9JZENhPTQwNQYJYIZIAYb4QgEN BCgWJmEgdGVzdCBjZXJ0aWZpY2F0ZSBmb3IgUGllcnJlIERlIEJvZWNrMB0GA1UdDgQWBBS3 /3Uawwg/7WS5GGF2VBt5S2babDALBgNVHQ8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMIHHBgNVHSMEgb8wgbyAFB3Gqkxo8jPYniuQwaajND7lkzVJoYGgpIGdMIGa MRMwEQYKCZImiZPyLGQBGRMDY29tMSEwHwYKCZImiZPyLGQBGRMRbWlzc2lvbmNyaXRpY2Fs aXQxGTAXBgNVBAoTEE1pc3Npb24gQ3JpdGljYWwxCzAJBgNVBAsTAkNBMTgwNgYDVQQDEy9N aXNzaW9uIENyaXRpY2FsIFNBIFRydXN0IENlcnRpZmljYXRlIEF1dGhvcml0eYIBAzBdBgNV HRIEVjBUgQ5wZGVAbWlzY3JpdC5iZYZCaHR0cDovL3d3dy5taXNjcml0LmJlL0NsYXZpcy9k
Re: Subject Attribute Email has no known NID, skipped
Dr. Stephen Henson wrote: On Sun, Aug 31, 2003, Christian Barmala wrote: Hi Stephen, thank you for your fast reply. - Original Message - From: Dr. Stephen Henson [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 3:30 PM When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... Good to know that I don't have to search for the error on my side any longer. Email has been deleted as a short name in objects.txt between 0.9.6 and 0.9.7, I'll checkthe logs to see the reason. Email was deleted because it was not found in the standards. All RFCs use emailAddress and not email as the name of the PKCS#9 emailaddress. There is the attribute mail too but this is a rfc822Mailbox and not a PKCS#9 emailaddress. Don't ask me for the differences. We only checked the standards and used their terminology. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Attribute Email has no known NID, skipped
Hi Stephen, thank you for your fast reply. - Original Message - From: Dr. Stephen Henson [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 3:30 PM When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... Good to know that I don't have to search for the error on my side any longer. When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) It isn't part of the CN, that's just how its displayed: read the FAQ. http://www.openssl.org/support/faq.html doesn't contain the string email and only one instance of CN, which covers a different topic. http://www.openssl.org/support/faq.html#USER13 also covers a different topic. However since you told me that it's just an odd display, I generated a certificate from that request and it contained the correct DN. Case closed :-) Thank you, Christian __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Attribute Email has no known NID, skipped
On Sun, Aug 31, 2003, Christian Barmala wrote: Hi Stephen, thank you for your fast reply. - Original Message - From: Dr. Stephen Henson [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 3:30 PM When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... Good to know that I don't have to search for the error on my side any longer. Email has been deleted as a short name in objects.txt between 0.9.6 and 0.9.7, I'll checkthe logs to see the reason. When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) It isn't part of the CN, that's just how its displayed: read the FAQ. http://www.openssl.org/support/faq.html doesn't contain the string email and only one instance of CN, which covers a different topic. http://www.openssl.org/support/faq.html#USER13 also covers a different topic. #13 is actually the right topic. That odd email display is a symptom of the old behaviour. Though it could be clearer. -nameopt oneline or -nameopt multiline produces a more sensible output. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Attribute Email has no known NID, skipped
On Sun, Aug 31, 2003, Christian Barmala wrote: Hi, I try to create a certificate request with OpenSSL 0.9.7b openssl req -subj /C=DE/ST=Nordrheinwestfalen/L=Oberhausen/O=ABCGmbH/OU=Internet/CN=User /[EMAIL PROTECTED] or ... /[EMAIL PROTECTED] This should be correct, because objects.h define #define SN_pkcs9_emailAddress Email #define LN_pkcs9_emailAddress emailAddress When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) It isn't part of the CN, that's just how its displayed: read the FAQ. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Subject Attribute Email has no known NID, skipped
Hi, I try to create a certificate request with OpenSSL 0.9.7b openssl req -subj /C=DE/ST=Nordrheinwestfalen/L=Oberhausen/O=ABCGmbH/OU=Internet/CN=User /[EMAIL PROTECTED] or ... /[EMAIL PROTECTED] This should be correct, because objects.h define #define SN_pkcs9_emailAddress Email #define LN_pkcs9_emailAddress emailAddress When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) Is this a known bug or am I doing something wrong? Christian Barmala __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: renewal = same key,same subject and new serial ???
In message [EMAIL PROTECTED] on Tue, 25 Mar 2003 16:50:01 +0700, Blue-Boonchai Aussawasongsilp [EMAIL PROTECTED] said: boonchai.a i serach some information and summarize by myself is boonchai.a renewal = same key,same subject and new serial . boonchai.a boonchai.a but i test renewal cerificate with signed document by old cert. boonchai.a it's not work i mean can't replace renewal cert to old cert completely. boonchai.a ex, i encrypt with old cert but can't decrypt with renew cert. boonchai.a boonchai.a and i gen new cert which same key,same subject and same serial ,test with boonchai.a old cert boonchai.a result it's completely replacement boonchai.a i mean , i encrypt with old cert and can decrypt with new cert (same boonchai.a serial). boonchai.a boonchai.a this is my problem boonchai.a i think renewal = same key,same subject and new serial and completely boonchai.a replacement boonchai.a but completely replacement requrie same serial boonchai.a boonchai.a really, renewal ceritificate is same/new serial ?? boonchai.a renewal should completely replacement??? From a PKI theory point of view, if you have a new certificate with the same key, you should have no problems, since the key is what you use for decryption. The serial number is irrelevant at this point. However, if the software in question has, for some reason, been foolish enough to store a hash of your old cert, or something containing the old certificate's serial number, and needs that data to match, I can see where your problem is. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ 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 http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
renewal = same key,same subject and new serial ???
dear all, i serach some information and summarize by myself is renewal = same key,same subject and new serial . but i test renewal cerificate with signed document by old cert. it's not work i mean can't replace renewal cert to old cert completely. ex, iencrypt with old cert but can't decrypt with renew cert. and i gen new cert which same key,same subject and same serial ,test with old cert result it's completely replacement i mean , iencrypt with old certand can decrypt with new cert (same serial). this is my problem i think renewal = same key,same subject and new serial and completely replacement but completely replacement requrie same serial really, renewal ceritificate is same/new serial ?? renewal should completely replacement??? thank ** Message from InterScan E-Mail VirusWall NT ** ** No virus found in attached file noname.htm * End of message ***
[no subject]
hi i am trying to sign a document in the smime format,i did this either by using the command smime or using the PKCS7_sign and SMIME_write_PKCS7 but when i tried to verify the signed file with smime -verify i obtain a message : Segmentation fault (core dumped) and when i tried with the function : PKCS7_verify, it always return zero (fail) ,well i follow the source code debugging and i found that the problem was in the funcion PKCS7_signatureVerify and precisely in the function (memcmp(message_digest-data,md_dat,md_len)) when it try to compare the digests , this function return a non zero value (the two digests are not the same) please could someone tell me what is the problem, and if there is a bug or an error , and if someone could give me an example about how to make a tested S/MIME signing/verifying procedure thanx _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #362] [no subject]
OUTPUT OF ./config -t Operating system: 9000/785-hp-hpux11 Configuring for hpux11 /usr/contrib/bin/perl ./Configure hpux11 Following the error reported by the command make after running ./Configure hpux11-64bit-cc on a system HP-UX hpiv113 B.11.11 U 9000/785 2016775763 unlimited-user license Please let me know as soon as you can. Thanks id advance Romana Rubino Majner __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] AutoReply: [no subject]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
On Mon, Nov 25, 2002 at 10:22:37AM +0100, Romana Rubino via RT wrote: OUTPUT OF ./config -t Operating system: 9000/785-hp-hpux11 Configuring for hpux11 /usr/contrib/bin/perl ./Configure hpux11 Following the error reported by the command make after running ./Configure hpux11-64bit-cc on a system HP-UX hpiv113 B.11.11 U 9000/785 2016775763 unlimited-user license I don't see any error message included. 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: [openssl.org #362] [no subject]
Sorry (See attached file: err) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
I already have a gcc installed (that one GNU). Can you know it is ok? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #362] [no subject]
How can I force the use of gcc? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
[[EMAIL PROTECTED] - Thu Sep 5 09:23:59 2002]: This patch is a replacement for RT/openssl.org: Ticket #237. Please retract Ticket #237. The following patch provides basic support for Subject Directory Attributes, which are defined in the x509 spec (RFC 2459), but are currently unsupported by OpenSSL. openssl.cnf entries for Subject Directory Attributes should be formed as follows: subjectDirectoryAttribute = type:type-objectname, \ value:value-objectname|DER:hexstring Example: subjectDirectoryAttributes = type:corestreet,value:DER:3081cd3081ca3081ca... An OID for Corestreet Credential Validation has also been added to provide support for Dr. Silvio Micali's certificate validation mechanism. The follow diff is relative to the 9/03/02 snapshot. The new ASN1 generator in OpenSSL 0.9.8 should be able to do this using a human readable syntax. See ASN1_generate_nconf(3) and doc/openssl.txt in 0.9.8 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
Hello! I am using smime-tool for creating SMIME messages. I found and option which I can use to extract signer's certificate when verifying the message. How I can extract encryption Certificates used to encrypt the message? I found how to extract issuer_and_serial from PKCS7 structure, but I still cannot extract Certificates used to encrypt the message. (PKCS7_RECIP_INFO *ri;) I tried to get the value of ri-cert, but unfortunately it didn't work. Are encryption Certificates included in SMIME message, or just information about them is included - like issuer name and serial number)? Maya
How can I create a X509_NAME by a subject string
I have got a subject string of the certification. And I want to use this string to find out the proper X509 object in a stack. I know the method X509 *X509_find_by_subject(STACK_OF(X509) *sk,X509_NAME *name); ,but I don't know how to construct a X509_NAME object by giving a subject string like /C=CN/O=X.inc/CN=XXX. Can anybody help me? thx!! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #269] [PATCH] Support for Subject Directory Attributes redux
This patch is a replacement for RT/openssl.org: Ticket #237. Please
retract Ticket #237.
The following patch provides basic support for Subject Directory
Attributes, which are defined in the x509 spec (RFC 2459), but are
currently unsupported by OpenSSL. openssl.cnf entries for Subject
Directory Attributes should be formed as follows:
subjectDirectoryAttribute = type:type-objectname, \
value:value-objectname|DER:hexstring
Example:
subjectDirectoryAttributes = type:corestreet,value:DER:3081cd3081ca3081ca...
An OID for Corestreet Credential Validation has also been added to
provide support for Dr. Silvio Micali's certificate validation mechanism.
The follow diff is relative to the 9/03/02 snapshot.
Index: crypto/objects/obj_dat.h
===
RCS file:
/home/jhartford/projects/openssl/cvs/openssl/crypto/objects/obj_dat.h,v
retrieving revision 1.62
diff -c -r1.62 obj_dat.h
*** crypto/objects/obj_dat.h2002/08/02 12:28:33 1.62
--- crypto/objects/obj_dat.h2002/09/04 18:01:32
***
*** 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 716
! #define NUM_SN 711
! #define NUM_LN 711
! #define NUM_OBJ 685
! static unsigned char lvalues[4849]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
--- 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 718
! #define NUM_SN 713
! #define NUM_LN 713
! #define NUM_OBJ 687
! static unsigned char lvalues[4860]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
***
*** 753,758
--- 753,760
0x67,0x2B,0x0D,0x04,0x0A,/* [4833]
OBJ_wap_wsg_idm_ecid_wtls10 */
0x67,0x2B,0x0D,0x04,0x0B,/* [4838]
OBJ_wap_wsg_idm_ecid_wtls11 */
0x67,0x2B,0x0D,0x04,0x0C,/* [4843]
OBJ_wap_wsg_idm_ecid_wtls12 */
+ 0x55,0x1D,0x09, /* [4848]
OBJ_subject_directory_attributes */
+ 0x2B,0x06,0x01,0x04,0x01,0xE0,0x35,0x01, /* [4851] OBJ_corestreet */
};
static ASN1_OBJECT nid_objs[NUM_NID]={
***
*** 1873,1878
--- 1875,1884
NID_wap_wsg_idm_ecid_wtls11,5,(lvalues[4838]),0},
{wap-wsg-idm-ecid-wtls12,wap-wsg-idm-ecid-wtls12,
NID_wap_wsg_idm_ecid_wtls12,5,(lvalues[4843]),0},
+ {subjectDirectoryAttributes,Subject Directory Attributes,
+ NID_subject_directory_attributes,3,(lvalues[4848]),0},
+ {corestreet,Corestreet Credential Validation,NID_corestreet,8,
+ (lvalues[4851]),0},
};
static ASN1_OBJECT *sn_objs[NUM_SN]={
***
*** 2054,2059
--- 2060,2066
(nid_objs[130]),/* clientAuth */
(nid_objs[131]),/* codeSigning */
(nid_objs[50]),/* contentType */
+ (nid_objs[717]),/* corestreet */
(nid_objs[53]),/* countersignature */
(nid_objs[153]),/* crlBag */
(nid_objs[103]),/* crlDistributionPoints */
***
*** 2555,2560
--- 2562,2568
(nid_objs[496]),/* singleLevelQuality */
(nid_objs[387]),/* snmpv2 */
(nid_objs[85]),/* subjectAltName */
+ (nid_objs[716]),/* subjectDirectoryAttributes */
(nid_objs[398]),/* subjectInfoAccess */
(nid_objs[82]),/* subjectKeyIdentifier */
(nid_objs[498]),/* subtreeMaximumQuality */
***
*** 2598,2603
--- 2606,2612
(nid_objs[285]),/* Biometric Info */
(nid_objs[179]),/* CA Issuers */
(nid_objs[131]),/* Code Signing */
+ (nid_objs[717]),/* Corestreet Credential Validation */
(nid_objs[382]),/* Directory */
(nid_objs[392]),/* Domain */
(nid_objs[132]),/* E-mail Protection */
***
*** 2662,2667
--- 2671,2677
(nid_objs[386]),/* Security */
(nid_objs[394]),/* Selected Attribute Types */
(nid_objs[143]),/* Strong Extranet ID */
+ (nid_objs[716]),/* Subject Directory Attributes */
(nid_objs[398]),/* Subject Information Access */
(nid_objs[130]),/* TLS Web Client Authentication */
(nid_objs[129]),/* TLS Web Server Authentication */
***
*** 3309,3316
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body 1 2 */
- (nid_objs[379]),/* OBJ_org 1 3 */
(nid_objs[527]),/* OBJ_identified_organization 1 3 */
(nid_objs[393]),/* OBJ_joint_iso_ccitt 2 */
(nid_objs[11]),/* OBJ_X500 2 5 */
(nid_objs[380]),/* OBJ_dod 1 3 6 */
--- 3319,3326
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
The following patch provides basic support for Subject Directory
Attributes, which are defined in the x509 spec (RFC 2459), but are
currently unsupported by OpenSSL. In this patch, Subject Directory
Attributes are parsed like Authority Information Access.
An OID for Corestreet Credential Validation has also been added to
provide support for Dr. Silvio Micali's certificate validation mechanism.
The follow diff is relative to the 8/15/02 snapshot.
Index: crypto/objects/obj_dat.h
===
RCS file:
/home/jhartford/projects/openssl/cvs/openssl/crypto/objects/obj_dat.h,v
retrieving revision 1.62
diff -c -b -r1.62 obj_dat.h
*** crypto/objects/obj_dat.h2002/08/02 12:28:33 1.62
--- crypto/objects/obj_dat.h2002/08/19 19:44:30
***
*** 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 716
! #define NUM_SN 711
! #define NUM_LN 711
! #define NUM_OBJ 685
! static unsigned char lvalues[4849]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
--- 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 718
! #define NUM_SN 713
! #define NUM_LN 713
! #define NUM_OBJ 687
! static unsigned char lvalues[4860]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
***
*** 753,758
--- 753,760
0x67,0x2B,0x0D,0x04,0x0A,/* [4833]
OBJ_wap_wsg_idm_ecid_wtls10 */
0x67,0x2B,0x0D,0x04,0x0B,/* [4838]
OBJ_wap_wsg_idm_ecid_wtls11 */
0x67,0x2B,0x0D,0x04,0x0C,/* [4843]
OBJ_wap_wsg_idm_ecid_wtls12 */
+ 0x55,0x1D,0x09, /* [4848]
OBJ_subject_directory_attribute */
+ 0x2B,0x06,0x01,0x04,0x01,0xE0,0x35,0x01, /* [4851] OBJ_corestreet */
};
static ASN1_OBJECT nid_objs[NUM_NID]={
***
*** 1873,1878
--- 1875,1884
NID_wap_wsg_idm_ecid_wtls11,5,(lvalues[4838]),0},
{wap-wsg-idm-ecid-wtls12,wap-wsg-idm-ecid-wtls12,
NID_wap_wsg_idm_ecid_wtls12,5,(lvalues[4843]),0},
+ {subjectDirectoryAttribute,Subject Directory Attribute,
+ NID_subject_directory_attribute,3,(lvalues[4848]),0},
+ {corestreet,Corestreet Credential Validation,NID_corestreet,8,
+ (lvalues[4851]),0},
};
static ASN1_OBJECT *sn_objs[NUM_SN]={
***
*** 2054,2059
--- 2060,2066
(nid_objs[130]),/* clientAuth */
(nid_objs[131]),/* codeSigning */
(nid_objs[50]),/* contentType */
+ (nid_objs[717]),/* corestreet */
(nid_objs[53]),/* countersignature */
(nid_objs[153]),/* crlBag */
(nid_objs[103]),/* crlDistributionPoints */
***
*** 2555,2560
--- 2562,2568
(nid_objs[496]),/* singleLevelQuality */
(nid_objs[387]),/* snmpv2 */
(nid_objs[85]),/* subjectAltName */
+ (nid_objs[716]),/* subjectDirectoryAttribute */
(nid_objs[398]),/* subjectInfoAccess */
(nid_objs[82]),/* subjectKeyIdentifier */
(nid_objs[498]),/* subtreeMaximumQuality */
***
*** 2598,2603
--- 2606,2612
(nid_objs[285]),/* Biometric Info */
(nid_objs[179]),/* CA Issuers */
(nid_objs[131]),/* Code Signing */
+ (nid_objs[717]),/* Corestreet Credential Validation */
(nid_objs[382]),/* Directory */
(nid_objs[392]),/* Domain */
(nid_objs[132]),/* E-mail Protection */
***
*** 2662,2667
--- 2671,2677
(nid_objs[386]),/* Security */
(nid_objs[394]),/* Selected Attribute Types */
(nid_objs[143]),/* Strong Extranet ID */
+ (nid_objs[716]),/* Subject Directory Attribute */
(nid_objs[398]),/* Subject Information Access */
(nid_objs[130]),/* TLS Web Client Authentication */
(nid_objs[129]),/* TLS Web Server Authentication */
***
*** 3309,3316
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body 1 2 */
- (nid_objs[379]),/* OBJ_org 1 3 */
(nid_objs[527]),/* OBJ_identified_organization 1 3 */
(nid_objs[393]),/* OBJ_joint_iso_ccitt 2 */
(nid_objs[11]),/* OBJ_X500 2 5 */
(nid_objs[380]),/* OBJ_dod 1 3 6 */
--- 3319,3326
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body 1 2 */
(nid_objs[527]),/* OBJ_identified_organization 1 3 */
+ (nid_objs[379]),/* OBJ_org 1 3 */
(nid_objs[393]),/* OBJ_joint_iso_ccitt 2 */
(nid_objs[11]),/* OBJ_X500 2 5 */
(nid_objs[380
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
[[EMAIL PROTECTED] - Wed Aug 21 22:21:34 2002]: The following patch provides basic support for Subject Directory Attributes, which are defined in the x509 spec (RFC 2459), but are currently unsupported by OpenSSL. In this patch, Subject Directory Attributes are parsed like Authority Information Access. An OID for Corestreet Credential Validation has also been added to provide support for Dr. Silvio Micali's certificate validation mechanism. The follow diff is relative to the 8/15/02 snapshot. Do you have an example of a certificate containing this extension, that is one not generated by OpenSSL? There are a number of areas of this patch which I'm not sure about, the ASN1 code doesn't seem to match the description in RFC2459 and the extension of GENERAL_NAME for example. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
hi forks, I am installing Openss0.9.6e on win2000, When I do nmake -f ms\ntdll.mak it shows it can't find stdlib.h and string.h in cryptlib.c and other problems. Please tell me: how can I solve this problem. just what kind of configure should I do? my platform is win2000 sp 2 and visual c++ 6.0. thanks! Jerry
[openssl.org #142] (no subject)
Dear all, I get error messages when I tryed to compile the latest version of openssl. I attach a logfile of make OpenSSL self-test report: OpenSSL version: 0.9.6d Last change: Fix crypto/asn1/a_sign.c so that 'parameters' is omitte... Options: -mips4 OS (uname): IRIX gold 6.5 10181059 IP32 OS (config): mips3-sgi-irix Target (default): irix-mips3-gcc Target: irix-mips3-gcc Compiler: gcc version 2.8.1 please reply directly to me because I am not a mailing-list users Marta Ferraroni -- Marta Ferraroni Universita' di Firenze Via della Lastruccia,5- 50019 Sesto Fiorentino Firenze-ITALIA e-mail: [EMAIL PROTECTED] tel: +39-055-457-3342 fax: +39-055-457- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #142] (no subject)
[[EMAIL PROTECTED] - Thu Jul 11 15:25:40 2002]: I get error messages when I tryed to compile the latest version of openssl. I attach a logfile of make... The error messages indicate, that there is something odd with your gcc setup. It seems, that the assembler used cannot correctly handle the code generated by your compiler. Can you compile other code without problems? In this case it would be a question of the compiler flags being used: -mips4 -mabi=n32 -mmips-as I am however no expert on IRIX problems... Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Subject Alternative Name : openssl and RFC 2459
Title: Subject Alternative Name : openssl and RFC 2459
Hi
I Have read RFC 2459 about Subject Alternative Name. This Subject Alternative Name is defined in this way :
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER}
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
But, openssl supports (only) the following GeneralName :
rfc822Name, dNSName, uniformResourceIdentifier, iPAddress, registeredID
Why theses restrictions?
Thank you very much
Re: Subject Alternative Name : openssl and RFC 2459
On Wed, May 15, 2002, CAMUS Sylvie FTRD/DTL/ISS wrote:
Hi
I Have read RFC 2459 about Subject Alternative Name. This Subject
Alternative Name is defined in this way :
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName[5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID[8] OBJECT IDENTIFIER}
OtherName ::= SEQUENCE {
type-idOBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner[0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
But, openssl supports (only) the following GeneralName :
rfc822Name, dNSName, uniformResourceIdentifier, iPAddress, registeredID
Why theses restrictions?
OpenSSL will parse and encode any of these.
It will however only display or generate the ones you mention.
This is for several reasons.
EDIPartyName, no real reason other than no one has wanted it.
OtherName is general purpose and is hard to handler generally,
though future versions of OpenSSL may handle simple string and
allow application to provide support for other forms based on
the type-id OID.
ORAddress: here be dragons!
Anyone unsure of the reason for that comment should have a look
at the definition of ORAddress...
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[no subject]
Keep getting a fatal error when trying to run the make command for openssl Here is the error: testing... cc -DMONOLITH -I../include -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=u ltra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM -c speed.c ucbcc: Warning: Option -YP,:/usr/ucblib:/opt/SUNWspro/WS6U2/bin/../lib:/opt/SUNWspro/WS6U2/bi n:/usr/ccs/lib:/usr/lib passed to ld, if ld is invoked, ignored otherwise ucbcc: Warning: -Xa redefines compatibility mode from SunC transition to ANSI /usr/ucbinclude/signal.h, line 49: syntax error before or at: int /usr/ucbinclude/signal.h, line 49: warning: undefined or missing type for: int *** Error code 2 make: Fatal error: Command failed for target `speed.o' Current working directory /usr/openssl-0.9.6c/apps *** Error code 1 make: Fatal error: Command failed for target `apps' Current working directory /usr/openssl-0.9.6c/test *** Error code 1 make: Fatal error: Command failed for target `tests' Please share any insight into this. Jeffery M. Yarbrough [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #21] [no subject]
Hello I found your contact information while looking for information about B2B exchanges. I believe that I have came up with a fresh concept for creating communities for B2B exchanges with unlimited streaming video, audio and PowerPoint presentations. I am genuinely interested in your feedback. Please take a look at www.AdrenaMail.com. I am genuinly interested in your feedback. Your feedback means a lot to me. Thank You David Evgey- President AdrenaMail Corp. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
Please Remove my name from the list.
[no subject]
There is an input sanity check in asn1_lib.c that is #if'd out for some reason. In its absence, a corrupt certificate read by d2i_X509() can at least crash the process. Additionally, the sanity checks both there and in a_bytes.c do not take into account a possibility of negative length and of pointer wrap-around, with similar results. Code to demonstrate the bug (just run it for a few hours) and a diff are attached. Was the #if'ing out of the test intentional, and am I risking anything by enabling it? Right now I am patching openssl-engine-0.9.6c privately, but of course I'd be much happier to know I'd be able to just use plain vanilla 0.9.6d. Thanks for the excellent library, and thanks in advance for your reply, -- Adi Stav - developer Topaz Prism RD Mercury Interactive +972-3-5399481 [EMAIL PROTECTED] test_d2i_X509.c Description: Binary data openssl.diff Description: Binary data
new oid in subject alt name
Title: new oid in subject alt name
Hi
I want to add a new oid in the subject altname and I can't do it.
I have look at sources (v3.alt.c) and i have seen the function which returns an error :
--
GENERAL_NAME *v2i_GENERAL_NAME(X509V3_EXT_METHOD *method, X509V3_CTX *ctx,
CONF_VALUE *cnf)
{
char is_string = 0;
int type;
GENERAL_NAME *gen = NULL;
char *name, *value;
name = cnf-name;
value = cnf-value;
if(!value) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,X509V3_R_MISSING_VALUE);
return NULL;
}
if(!(gen = GENERAL_NAME_new())) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,ERR_R_MALLOC_FAILURE);
return NULL;
}
if(!name_cmp(name, email)) {
is_string = 1;
type = GEN_EMAIL;
} else if(!name_cmp(name, URI)) {
is_string = 1;
type = GEN_URI;
} else if(!name_cmp(name, DNS)) {
is_string = 1;
type = GEN_DNS;
} else if(!name_cmp(name, RID)) {
ASN1_OBJECT *obj;
if(!(obj = OBJ_txt2obj(value,0))) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,X509V3_R_BAD_OBJECT);
ERR_add_error_data(2, value=, value);
goto err;
}
gen-d.rid = obj;
type = GEN_RID;
} else if(!name_cmp(name, IP)) {
int i1,i2,i3,i4;
unsigned char ip[4];
if((sscanf(value, %d.%d.%d.%d,i1,i2,i3,i4) != 4) ||
(i1 0) || (i1 255) || (i2 0) || (i2 255) ||
(i3 0) || (i3 255) || (i4 0) || (i4 255) ) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,X509V3_R_BAD_IP_ADDRESS);
ERR_add_error_data(2, value=, value);
goto err;
}
ip[0] = i1; ip[1] = i2 ; ip[2] = i3 ; ip[3] = i4;
if(!(gen-d.ip = M_ASN1_OCTET_STRING_new()) ||
!ASN1_STRING_set(gen-d.ip, ip, 4)) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,ERR_R_MALLOC_FAILURE);
goto err;
}
type = GEN_IPADD;
} else {
X509V3err(X509V3_F_V2I_GENERAL_NAME,X509V3_R_UNSUPPORTED_OPTION);
ERR_add_error_data(2, name=, name);
goto err;
}
if(is_string) {
if(!(gen-d.ia5 = M_ASN1_IA5STRING_new()) ||
!ASN1_STRING_set(gen-d.ia5, (unsigned char*)value,
strlen(value))) {
X509V3err(X509V3_F_V2I_GENERAL_NAME,ERR_R_MALLOC_FAILURE);
goto err;
}
}
gen-type = type;
return gen;
err:
GENERAL_NAME_free(gen);
return NULL;
}
---
Now, i understand why i cannot add a new oid in the subject altname.
But, i don't understand theses restrictions about oids accepted for subject alt name (email,ip,...)? What are the reasons?
Thank you very much.
ps : i have alreeady sent this mail in openssl-users mailing list but i haven't received any answer.
[no subject]
Bonjour, I am trying to install Openssl on my computer: a fatal error return happens : making all in crypto/sha... cc -I.. -I../../include -DTHREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings -c sha_dgst.c Fatal: Insufficient virtual memory to continue compilation. My computer is dec alpha xp1000 OSF 4.0F Please - can you help me Best regards, [EMAIL PROTECTED] tel: 33 (0)1 6915 8223 NB __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[no subject]
OpenSSL Bug report Tue Mar 19 11:07:02 PST 2002 From: Linda Gay Thompson NASA Ames Research Center, Mt. View, Ca. 94035 I had the same problem when compiling with the -O3 flag. Please send email response to: [EMAIL PROTECTED] OpenSSL self-test report: OpenSSL version: 0.9.6c Last change: Fix BN_rand_range bug pointed out by Dominikus Scherkl... Options: -mips3 OS (uname): IRIX tanagra 6.5 10100655 IP22 OS (config): mips3-sgi-irix Target (default): irix-mips3-gcc Target: irix-mips3-gcc Compiler: Configured with: ../configure --prefix=/usr/freeware --enable-version-specific-runtime-libs --disable-shared --enable-threads --enable-haifa Thread model: single gcc version 3.0.1 Failure! - + rm -f libcrypto.so.0 + rm -f libcrypto.so + rm -f libcrypto.so.0.9.6 + rm -f libssl.so.0 + rm -f libssl.so + rm -f libssl.so.0.9.6 making all in crypto... ( echo #ifndef MK1MF_BUILD; \ echo /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */; \ echo #define CFLAGS \gcc -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W\; \ echo #define PLATFORM \irix-mips3-gcc\; \ echo #define DATE \`date`\; \ echo #endif ) buildinf.h gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c cryptlib.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c mem.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c mem_dbg.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c cversion.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c ex_data.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c tmdiff.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c cpt_err.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c ebcdic.c gcc -I. -I../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c uid.c ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o tmdiff.o cpt_err.o ebcdic.o uid.o ar: Warning: creating ../libcrypto.a You may get an error following this line. Please ignore. true ../libcrypto.a making all in crypto/md2... gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md2_dgst.c gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md2_one.c ar r ../../libcrypto.a md2_dgst.o md2_one.o You may get an error following this line. Please ignore. true ../../libcrypto.a making all in crypto/md4... gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md4_dgst.c gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md4_one.c ar r ../../libcrypto.a md4_dgst.o md4_one.o You may get an error following this line. Please ignore. true ../../libcrypto.a making all in crypto/md5... gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md5_dgst.c gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c md5_one.c ar r ../../libcrypto.a md5_dgst.o md5_one.o You may get an error following this line. Please ignore. true ../../libcrypto.a making all in crypto/sha... gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c sha_dgst.c gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c sha1dgst.c gcc -I.. -I../../include -DTHREADS -D_SGI_MP_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -mips3 -mabi=n32 -mmips-as -DTERMIOS -DB_ENDIAN -DBN_DIV3W -c sha_one.c
Re: Subject: -lsocket missing for Solaris 2.6
On Thu, 21 Feb 2002, Jonsson Per-Arne S. wrote: Hello! I have problem with the syntax and where to add lsocket into the Makefile. What config target are you using? What does the EX_LIBS= line in Makefile say? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
