[openssl-dev] tls_enc() and pad/aad failures (detected behavior change after 1.0.1p)
Hi all,
we are facing a weird problem that we started to notice recently and we
could not really find the source of the issue. The issue presented
itself when starting using OpenSSL v1.0.1p (upgrading from v1.0.1m) in
TLS connections. We started noticing the following error:
error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert ad record mac
This seems to be related to the SSL_AD_BAD_RECORD_MAC. Since this error
happens randomly and it is very difficult to reproduce, I tried to see
the changes in the tls1_enc() function (t1_enc.c) from the ssl, which is
used in the SSL_ENC_METHOD for enc/dec the records. I noticed the
following change:
/* openssl v1.0.1m/ssl/t1_enc.c */:
812: pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD, 13, buf);
813: if (send) {
While in the updated version:
/* openssl v1.0.1p/ssl/t1_enc.c */
812: pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD,
813: EVP_AEAD_TLS1_AAD_LEN, buf);
814:if (pad <= 0)
815:return -1;
816:if (send) {
This change seems pretty interesting, as it might be related to the
errors we have started seeing after the upgrade. Now, my questions are
(given this might be the source of the error):
* Has anybody noticed the different behavior (the same code from
1.0.1p is in the current 1.0.2e - plus some additional checks for
DTLS) ?
* If the pad <= 0 is detected (not checked before), what can cause the
error ? Network errors should be detected at the TCP level, so... it
might be an application-level error ? Corrupted buffers ? Shooting
in the dark here...
Any ideas on how to fix the issue and/or to understand if this is an
OpenSSL issue or an application layer issue that would be really
appreciated. I am not sure how to proceed at this point.. help ?
Thanks,
Max
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest
Hi OpenSSL Community, I originally posted this message on the security area ML at IETF and I am trying to reach out to a broad audience of experts, implementers, and vendors. I would love to have contributions and implementations (once we have some initial specs) around this initiative. I am still trying to find the right host for the mailing list where to discuss all aspects of this initiative, but I hope that this message will spark some interest and (especially from one of the most vibrant crypto library community out there) possibly inspire the community to join the envisioned effort. Any comments and feedback are welcome (positive and negative alike). Cheers, Max Forwarded Message Subject:[saag] Standard Crypto API + Symmetric Crypto At Rest Date: Sat, 7 Nov 2015 22:30:35 +0900 From: Massimiliano Pala <direc...@openca.org> Organization: OpenCA Labs To: s...@ietf.org <s...@ietf.org> Hi all, I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail. The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities). Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at: http://cryptoapi.openca.org/ Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest". Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address. Happy Security Everybody! Cheers, Max P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS). ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Reporting an Issue with OpenSSL in MacOS SDK 10.8
That's right - I missed that (my bad!). Thanks. Cheers, Max On 7/22/14, 7:02 PM, Viktor Dukhovni wrote: On Tue, Jul 22, 2014 at 09:37:13AM -0400, Massimiliano Pala wrote: working on porting my libpki implementation (based on OpenSSL) to MacOS I found out an issue that is not really related to the code itself but the distributed version in the SDK. Apple ships OpenSSL 0.9.8. In particular, I found out that several functions' signatures have been altered in their return codes. This is particularly scary as they removed the ability to verify the return code by changing the return type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), HMAC_Final(). The OpenSSL 0.9.8 interface did not return errors from these functions: commit 87d52468aa600e02326e13f01331e1f3b8602ed0 Author: Dr. Stephen Henson st...@openssl.org Date: Sun Nov 2 16:00:39 2008 + Update HMAC functions to return an error where relevant. $ git branch --contains 87d52468aa600e02326e13f01331e1f3b8602ed0 OpenSSL_1_0_0-stable OpenSSL_1_0_1-stable OpenSSL_1_0_2-stable * master I am not sure if this is an issue or if any of the people subscribed here from Apple could explain why they changed an API that is not theirs and that causes portability issues of applications that are based on OpenSSL. Apple did not change this interface, they provide an older version. OpenSSL 0.9.8 and 1.0.0 are neither source nor binary compatible. Some porting is required between these releases. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reporting an Issue with OpenSSL in MacOS SDK 10.8
Hi all, working on porting my libpki implementation (based on OpenSSL) to MacOS I found out an issue that is not really related to the code itself but the distributed version in the SDK. In particular, I found out that several functions' signatures have been altered in their return codes. This is particularly scary as they removed the ability to verify the return code by changing the return type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), HMAC_Final(). I don't know if there are others. I am not sure if this is an issue or if any of the people subscribed here from Apple could explain why they changed an API that is not theirs and that causes portability issues of applications that are based on OpenSSL. But I think this is a big mistake from Apple and if we could manage to have them to actually include a non-modified version of the API (or at least change the names of include/lib so that applications will not have compiling issues and/or binary incompatibilities), that would be a good outcome. This, of course, unless I am missing an important reason - so far, my contacts at Apple were not able to give any real reasons for that odd changes other than (quote) it must be that Apple looked at the code and those functions can not fail.. besides what would you do if that fails ? (arguably, a very wrong answer also considering it is not an Apple's internal API). Best, Dr. Pala __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reporting an Issue with OpenSSL in MacOS SDK 10.8
Hi all, working on porting my libpki implementation (based on OpenSSL) to MacOS I found out an issue that is not really related to the code itself but the distributed version in the SDK. In particular, I found out that several functions' signatures have been altered in their return codes. This is particularly scary as they removed the ability to verify the return code by changing the return type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), HMAC_Final(). I don't know if there are others. I am not sure if this is an issue or if any of the people subscribed here from Apple could explain why they changed an API that is not theirs and that causes portability issues of applications that are based on OpenSSL. But I think this is a big mistake from Apple and if we could manage to have them to actually include a non-modified version of the API (or at least change the names of include/lib so that applications will not have compiling issues and/or binary incompatibilities), that would be a good outcome. This, of course, unless I am missing an important reason - so far, my contacts at Apple were not able to give any real reasons for that odd changes other than (quote) it must be that Apple looked at the code and those functions can not fail.. besides what would you do if that fails ? (arguably, a very wrong answer also considering it is not an Apple's internal API). Best, Dr. Pala __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reporting an Issue with OpenSSL in MacOS SDK 10.8
Hi all, working on porting my LibPKI implementation (based on OpenSSL) to MacOS I found out an issue that is not really related to the code itself but the distributed version in the SDK. In particular, I found out that several functions' signatures have been altered in their return codes. This is particularly scary as they removed the ability to verify the return code by changing the return type to void. An example of this is: HMAC_Init_ex(), HMAC_Update(), HMAC_Final(). I don't know if there are others functions that have been redacted, but I expect that to be true. I am not sure if this is an issue or if any of the people subscribed here from Apple could explain why they changed an API that is not theirs and that causes portability issues of applications that are based on OpenSSL. But I think this is a big mistake from Apple and if we could manage to have them to actually include a non-modified version of the API (or at least change the names of include/lib so that applications will not have compiling issues and/or binary incompatibilities), that would be a good outcome. This, of course, unless I am missing an important reason - so far, my contacts at Apple were not able to give any real reasons for that odd changes other than (quote) it must be that Apple looked at the code and those functions can not fail.. besides what would you do if that fails ? (arguably, a very wrong answer also considering it is not an Apple's internal API). Best, Dr. Pala __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
EC Key Version
Hello, it seems that there are two different encoding versions when encoding EC keys. In particular, if using the EVP_PKEY_() the version is set to 0 - and that is incompatible with software other than OpenSSL. Here's an example: -BEGIN PRIVATE KEY- MGcCAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcETTBLAgEBBCDxE4JqRGtcOqVjy8wM gI/eDocdjKO4nVaSRRmeAiNeWaEkAyIAAua6xRQ8yyLt6j0+g8nS6P5LzsQqaPTN /HwjnCW/S0VN -END PRIVATE KEY- To reproduce, simply use the openssl pkey command: $ openssl pkey -in key.pem | openssl asn1parse The output is: 0:d=0 hl=2 l= 103 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 19 cons: SEQUENCE 7:d=2 hl=2 l= 7 prim: OBJECT:id-ecPublicKey 16:d=2 hl=2 l= 8 prim: OBJECT:prime256v1 26:d=1 hl=2 l= 77 prim: OCTET STRING ... On the other hand, if using the i2d_ECPrivateKey_bio() the version is automatically set to 1. To reproduce, just use the openssl ec command: $ openssl ec -in key.pem | openssl asn1parse The output is: 0:d=0 hl=2 l= 87 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:F113... 39:d=1 hl=2 l= 10 cons: cont [ 0 ] 41:d=2 hl=2 l= 8 prim: OBJECT:prime256v1 51:d=1 hl=2 l= 36 cons: cont [ 1 ] 53:d=2 hl=2 l= 34 prim: BIT STRING So.. is there a way to have the EVP_PKEY_* code path behave as the ECPrivateKey_bio() code path ? Is this a bug ? Any idea how to fast-fix it ? Cheers, Max smime.p7s Description: S/MIME Cryptographic Signature
Re: EC Key Version :: Hack-Solved
Hi all,
if anybody is curious about how to fix the issue, here it is... :D
The problem is that functions like PEM_write_bio_PKCS8PrivateKey() or
PEM_write_bio_PrivateKey() do not encode the key correctly - therefore
there might be compatibility issues.
To solve the problem, you have to use the PEM_write_bio_ECPrivateKey()
function directly. For example:
switch( EVP_PKEY_type( x-type ))
{
case EVP_PKEY_DSA:
case EVP_PKEY_RSA:
ret = PEM_write_bio_PrivateKey( bp, x, enc, kstr, klen, cb, u);
break;
case EVP_PKEY_EC:
ret = PEM_write_bio_ECPrivateKey(bp, x-pkey.ec, enc, kstr, klen, cb,
u);
break;
default:
ret = 0;
};
...
This encodes the key correctly.
If there is a more elegant way to solve the issue.. let me know :D
Best,
Max
On 03/27/2011 06:03 PM, Massimiliano Pala wrote:
Hello,
it seems that there are two different encoding versions when encoding
EC keys. In particular, if using the EVP_PKEY_() the version is set to
0 - and that is incompatible with software other than OpenSSL.
Here's an example:
-BEGIN PRIVATE KEY-
MGcCAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcETTBLAgEBBCDxE4JqRGtcOqVjy8wM
gI/eDocdjKO4nVaSRRmeAiNeWaEkAyIAAua6xRQ8yyLt6j0+g8nS6P5LzsQqaPTN
/HwjnCW/S0VN
-END PRIVATE KEY-
To reproduce, simply use the openssl pkey command:
$ openssl pkey -in key.pem | openssl asn1parse
The output is:
0:d=0 hl=2 l= 103 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :00
5:d=1 hl=2 l= 19 cons: SEQUENCE
7:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
16:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
26:d=1 hl=2 l= 77 prim: OCTET STRING ...
On the other hand, if using the i2d_ECPrivateKey_bio() the version is
automatically set to 1.
To reproduce, just use the openssl ec command:
$ openssl ec -in key.pem | openssl asn1parse
The output is:
0:d=0 hl=2 l= 87 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :01
5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:F113...
39:d=1 hl=2 l= 10 cons: cont [ 0 ]
41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
51:d=1 hl=2 l= 36 cons: cont [ 1 ]
53:d=2 hl=2 l= 34 prim: BIT STRING
So.. is there a way to have the EVP_PKEY_* code path behave as the
ECPrivateKey_bio() code path ?
Is this a bug ? Any idea how to fast-fix it ?
Cheers,
Max
--
Best Regards,
Massimiliano Pala
--o
Massimiliano Pala [OpenCA Project Manager] ope...@acm.org
project.mana...@openca.org
Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory Work Phone: +1 (603) 646-8734
--o
People who think they know everything are a great annoyance to those of us
who do.
-- Isaac Asimov
smime.p7s
Description: S/MIME Cryptographic Signature
EC_KEY_set_enc_flags()
Hello guys, do you know what are the real effects of the EC_KEY_set_enc_flags() function ? I tried to use it to force the implicitCurve type of encoding in a cert.. but it did not work: // pkey - has the key in the cert ecKey = EVP_PKEY_get0(pkey); EC_KEY_set_enc_flags( ecKey, EC_PKEY_NO_PARAMETERS ); ... Cheers, Max smime.p7s Description: S/MIME Cryptographic Signature
Re: EC curve names
Hello Peter, all,
thanks for the hint.. but I was actually looking more at a way to check if
a certificate has been signed with one of the curves you listed. Maybe it is
not possible, but it would be nice to be able to say this certificate has
been signed with P-256 - since this can be a requirement for rejecting or
accepting a certificate.
The other solution is to extract the key from the signer's certificate, check
the signature with it and, if it checks out, check that the key is of a
particular curve... is there any better way to do it ?
Cheers,
Max
On 03/22/2011 12:14 AM, Peter Waltenberg wrote:
The only good way I found was to use the defined OID's - something like
this - no guarantees this table is correct, you should check it.
const char *NIST_by_OID[] = {
1.2.840.10045.3.1.1, /* P-192 */
1.3.132.0.33,/* P-224 */
1.2.840.10045.3.1.7, /* P-256 */
1.3.132.0.34,/* P-384 */
1.3.132.0.35,/* P-521 */
1.3.132.0.1, /* K-163 */
1.3.132.0.26,/* K-233 */
1.3.132.0.16,/* K-283 */
1.3.132.0.36,/* K-409 */
1.3.132.0.38,/* K-571 */
1.3.132.0.15,/* B-163 */
1.3.132.0.27,/* B-233 */
1.3.132.0.17,/* B-283 */
1.3.132.0.37,/* B-409 */
1.3.132.0.39,/* B-571 */
NULL
};
OBJ_txt2nid() will handle these as well as the names you are more familliar
with.
Peter
smime.p7s
Description: S/MIME Cryptographic Signature
Re: EC curve names
Hello Stephen, all, thanks for all the advices, I ended up doing the following: 1. Grab the Key from the Certificate 2. Cycle through the built-in curves 3. Generate a new point from the Key's group 4. if order(curve[i]) == order(key) and point is on curve[i] == curve found! ; return nid 5. i++ ; goto 4 This works. By comparing the nid with the required nid, I shall be guaranteed that the key used to signed is on the specific nid. Do you see any flaws ? BTW, for check of point 4 - I had to add it because otherwise I had multiple hits on different curves. Initially I expected that that check would be performed in the EC_POINT_is_on_curve().. maybe is a check that should be added there ? Cheers, Max On 03/22/2011 10:47 AM, Dr. Stephen Henson wrote: On Tue, Mar 22, 2011, Massimiliano Pala wrote: Hello Peter, all, thanks for the hint.. but I was actually looking more at a way to check if a certificate has been signed with one of the curves you listed. Maybe it is not possible, but it would be nice to be able to say this certificate has been signed with P-256 - since this can be a requirement for rejecting or accepting a certificate. The other solution is to extract the key from the signer's certificate, check the signature with it and, if it checks out, check that the key is of a particular curve... is there any better way to do it ? Are you talking programattically or by parsing text output of an OpenSSL utility? It should be easy enough programatically. BTW as regards curve names and their NID equivalents: I looked into this for the ECDSA tests for the latest validation. There's a translation function in fips/ecdsa/fips_ecdsavs.c which I'm fairly confident is correct as it passes the test vectors I've thrown at it. 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 -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
Re: EC curve names
Hi Douglas, the issue here is to be sure that things are done correctly - e.g., for testing that the crypto used by the CA issuing a certificate is ok. In any case, the NID from the signer can be missing (in fact, AFAIK, the curves should be provided with explicit params - implicit params are deprecated) - so you can not (1) rely on the presence of the NID, and (2) trust that the issuer is not lying. If the issuer is lying about the NID - then I don't trust it... checking is always good! :D Also, I might have the CA as a trusted anchor but I might want to restrict the usage of certificates that have been signed with a particular group.. (that's my goal). Thanks for your help and comments! Cheers, Max On 03/22/2011 12:02 PM, Douglas E. Engert wrote: On 3/22/2011 10:10 AM, Massimiliano Pala wrote: Hello Stephen, all, thanks for all the advices, I ended up doing the following: 1. Grab the Key from the Certificate 2. Cycle through the built-in curves 3. Generate a new point from the Key's group 4. if order(curve[i]) == order(key) and point is on curve[i] == curve found! ; return nid 5. i++ ; goto 4 This works. By comparing the nid with the required nid, I shall be guaranteed that the key used to signed is on the specific nid. Do you see any flaws ? I am not sure if the above is correct or not, but the process of verifying the signature should verify the curve is correct as well. During the verify you have the pubkey of the signer, the (questionable?) curve NID from the signer, the certificate to be verified and its signature. Your verify routine takes the NID and maps it to the built-in curve parameters, contained in the openssl library. So you know the signature is valid, using the built-in parameters of the named curve. (You must be trusting the openssl library to have the correct curve parameters, is any case.) So I don't see why you can not trust the NID in the signer's certificate is valid. If you don't trust the the signer has provided the correct NID, why would you trust the signer for anything else? BTW, for check of point 4 - I had to add it because otherwise I had multiple hits on different curves. Initially I expected that that check would be performed in the EC_POINT_is_on_curve().. maybe is a check that should be added there ? Cheers, Max On 03/22/2011 10:47 AM, Dr. Stephen Henson wrote: On Tue, Mar 22, 2011, Massimiliano Pala wrote: Hello Peter, all, thanks for the hint.. but I was actually looking more at a way to check if a certificate has been signed with one of the curves you listed. Maybe it is not possible, but it would be nice to be able to say this certificate has been signed with P-256 - since this can be a requirement for rejecting or accepting a certificate. The other solution is to extract the key from the signer's certificate, check the signature with it and, if it checks out, check that the key is of a particular curve... is there any better way to do it ? Are you talking programattically or by parsing text output of an OpenSSL utility? It should be easy enough programatically. BTW as regards curve names and their NID equivalents: I looked into this for the ECDSA tests for the latest validation. There's a translation function in fips/ecdsa/fips_ecdsavs.c which I'm fairly confident is correct as it passes the test vectors I've thrown at it. 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 -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
EC and implicitCurve
Hi guys, is it possible to have openssl write EC certs with the implicitCurve option in the ECParameters ? I need this for a test tool. In practice: - EC_KEY_set_asn1_flag(k, 1) = namedCurve - EC_KEY_set_asn1_flag(k, 0) = specifiedCurve But what about implicitCurve ? Is there a way ? Shall I try to change the type directly when generating the key (but how.. change the type to 2 ?) ? Cheers, Max -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
Re: How to add an alias to an Object / NID ? [solved]
Hi all, well.. I found a solution that works for now, although it might not be the most elegant. I just coded a new function that lets you create a new OBJ with a specific NID, in this way other parts of the code can use the new OBJ and retrieve the same NID for, for example, P384 and secp284r1. Cheers, Max P.S.: I also tried by using the OBJ_NAME_add with OBJ_NAME_ALIAS, but I could not figure out how to make it work for my purpose... :( On 01/15/2011 02:06 PM, Massimiliano Pala wrote: Hi all, I was wondering if it was possible to add an alias to an object. In particular, I would like to add the possibility, for example, to use P384 instead of secp384r1 when retrieving an object ID: name_1 = P384; name_2 = secp384r1; ret_1 = OBJ_txt2obj ( name_1, 0 ); ret_2 = OBJ_txt2obj ( name_2, 0 ); So that ret_1 and ret_2 point to the same object ? Or, at least, the following returns the same NID: nid_1 = OBJ_sn2nid ( name_1); nid_2 = OBJ_sn2nid ( name_2); == nid_1 == nid_2 Is there a way to do that ? Cheers, Max -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
How to add an alias to an Object / NID ?
Hi all, I was wondering if it was possible to add an alias to an object. In particular, I would like to add the possibility, for example, to use P384 instead of secp384r1 when retrieving an object ID: name_1 = P384; name_2 = secp384r1; ret_1 = OBJ_txt2obj ( name_1, 0 ); ret_2 = OBJ_txt2obj ( name_2, 0 ); So that ret_1 and ret_2 point to the same object ? Or, at least, the following returns the same NID: nid_1 = OBJ_sn2nid ( name_1); nid_2 = OBJ_sn2nid ( name_2); == nid_1 == nid_2 Is there a way to do that ? Cheers, Max smime.p7s Description: S/MIME Cryptographic Signature
OpenSSL's certificates and RFC-5280 (was Re: How may I contribute? :D)
Hello Kyle, can you elaborate on the quoted statement ? Since the RFC-5280 describes the profile for certificates and CRLs, how OpenSSL's generated certificates are not compatible with it? If you are referring to the configuration used, that's not really a concern of the OpenSSL's team, but if there are wrong encoding rules in the library can you point them out, please ? Cheers, Max On 07/13/2010 09:09 PM, aerow...@gmail.com wrote: [...] There's also the need to ensure that the certificates that OpenSSL comes up with are compatible with X.509 and PKIX (they are *not* currently compatible with the latest version of PKIX, which is in RFC 5280; it's [...] -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
SSL and Certificates verification
Hi all, I have two issues when I am trying to verify the certificates from an SSL connection. In particular I have difficulties in understanding how to: - Add a set of certificates that are to be trusted (trust anchors..) - Add a set of certificates that might be needed to build the chain (not trust anchors.. ) - Accept a chain of certificates where a self-signed cert is present without that error to be the only one reported in the verify callback (i.e., are there any flags I can set to avoid the error ?) So far, from the source code, I thought that by using: store = SSL_CTX_get_cert_store(ctx); X509_STORE_add_cert (store, cert); ... ssl = SSL_new ( ctx ); I would add the cert to the trusted ones.. but it does not seem to work :( Where are the functions or the right pointers to do that without using the SSL_CTX_load_verify_locations() ??? -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
SSL and Certificates verification
Hi all, I have two issues when I am trying to verify the certificates from an SSL connection. In particular I have difficulties in understanding how to: - Add a set of certificates that are to be trusted (trust anchors..) - Add a set of certificates that might be needed to build the chain (not trust anchors.. ) - Accept a chain of certificates where a self-signed cert is present without that error to be the only one reported in the verify callback (i.e., are there any flags I can set to avoid the error ?) So far, from the source code, I thought that by using: store = SSL_CTX_get_cert_store(ctx); X509_STORE_add_cert (store, cert); ... ssl = SSL_new ( ctx ); I would add the cert to the trusted ones.. but it does not seem to work :( Where are the functions or the right pointers to do that without using the SSL_CTX_load_verify_locations() ??? -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] ope...@acm.org project.mana...@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov smime.p7s Description: S/MIME Cryptographic Signature
CRMF and SEQUENCE OF CertReq
Hi guys,
I am stuck with a simple (hopefully) problem that I do not know how to solve.
In particular I am trying to implement a CRMF simple interface. But I am not
sure how to code the CertReqMessages. From the ASN.1 specification (rfc4211)
it should be:
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
Initially I implemented it as:
ASN1_SEQUENCE (CRMF_REQ) = {
ASN1_SEQUENCE_OF( CRMF_REQ, requests, CRMF_CERT_REQ_MESSAGE )
} ASN1_SEQUENCE_END(CRMF_REQ)
IMPLEMENT_ASN1_FUNCTIONS(CRMF_REQ)
and the related:
typedef struct crmfReq_st {
STACK_OF(CRMF_CERT_REQ_MESSAGE) *requests;
} CRMF_REQ;
DECLARE_ASN1_FUNCTIONS(CRMF_REQ)
Would this work ? Or because it would be something like:
SEQUENCE
SEQUENCE OF CRMF_CERT_REQ_MESSAGE
it will not ? (Instead of being just one SEQUENCE is a SEQUENCE of a
SEQUENCE). How do I solve my problem ?
--
Best Regards,
Massimiliano Pala
--o
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
[EMAIL PROTECTED]
Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063Work Phone: +1 (603) 646-9179
--o
smime.p7s
Description: S/MIME Cryptographic Signature
Shared Libs on Linux-x86_64
Hi guys, I get an error when enabling the shared build on my RH machine. I enable the shared lib build with the following config command: $ ./Configure shared --prefix=/usr/local/openssl-0.9.9 linux-x86_64 The error I get is the following (only when I build the share libs, the static libs get build correctly): [ --==oooOOOooo==-- *OpenSSL SNAP - 20080318* --====--] /usr/bin/ranlib ../../libcrypto.a || echo Never mind. make[2]: Leaving directory `/home/madwolf/devel/originals/openssl-SNAP-20080318/crypto/ts' if [ -n libcrypto.so.0.9.9 libssl.so.0.9.9 ]; then \ (cd ..; make libcrypto.so.0.9.9); \ fi make[2]: Entering directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' make[3]: Entering directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' make[4]: Entering directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' /usr/bin/ld: libcrypto.a(aes_wrap.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC libcrypto.a(aes_wrap.o): could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [link_a.gnu] Error 1 make[4]: Leaving directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' make[3]: *** [do_linux-shared] Error 2 make[3]: Leaving directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' make[2]: *** [libcrypto.so.0.9.9] Error 2 make[2]: Leaving directory `/home/madwolf/devel/originals/openssl-SNAP-20080318' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/home/madwolf/devel/originals/openssl-SNAP-20080318/crypto' make: *** [build_crypto] Error 1 -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Re: Certs with ECDSA + SHA256
Thanks for the suggestion :D I am able to use the SNAP version (although I had to link statically my application because I have not being able to build the shared lib version on my system...), although the RSA with SHA2 gives me problem when I want to use the SHA384 or SHA512 (works ok with SHA224 or SHA256). Anybody have tried those (256) with RSA ? The error I get is when I try to sign the certificate (or the request) :( Later, Max Larry Bugbee wrote: is it possible to use ECDSA with EVP_MDs other than EVP_dss1() ? I am interested in use it with SHA256, especially in X509 signatures(eg., certificates, requests, etc... ). I was successful in pulling and building the 0.9.9 SNAP at ftp://ftp.openssl.org/snapshot/ ECDSA (various curves) with the SHA2 family worked just fine. My only problem: I could not build the .dylib files for MacOSX. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Certs with ECDSA + SHA256
Hi Guys,
is it possible to use ECDSA with EVP_MDs other than EVP_dss1() ? I am interested
in use it with SHA256, especially in X509 signatures (eg., certificates,
requests, etc... ).
I think that the algorithm OID is defined as:
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
but I can not find it defined (at least in 0.9.8x versions).
Anyone has tried it yet ? :D
Later,
Max
--
Best Regards,
Massimiliano Pala
--o
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
[EMAIL PROTECTED]
Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063Work Phone: +1 (603) 646-9179
--o
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Extension Encoding - segfault
Hi Allan, well I did not compile the libcrypto, but now I have and here it is the results from gdb: Program received signal SIGSEGV, Segmentation fault. do_ext_nconf (conf=0xbf8cfc48, ctx=0x0, ext_nid=89, crit=0, value=0x8055800 policyIdentifier;OID:1.3.444.21.222.1.1.1) at v3_conf.c:154 154 if(!ctx-db || !ctx-db_meth) (gdb) backtrace #0 do_ext_nconf (conf=0xbf8cfc48, ctx=0x0, ext_nid=89, crit=0, value=0x8055800 policyIdentifier;OID:1.3.444.21.222.1.1.1) at v3_conf.c:154 #1 0xb7f14eba in X509V3_EXT_nconf (conf=0xbf8cfc48, ctx=0x0, name=0x8069758 certificatePolicies, value=0x8055800 policyIdentifier;OID:1.3.444.21.222.1.1.1) at v3_conf.c:90 #2 0xb7f14faa in X509V3_EXT_conf (conf=0x0, ctx=0x0, name=0x8069758 certificatePolicies, value=0x8055800 policyIdentifier;OID:1.3.444.21.222.1.1.1) at v3_conf.c:462 I figured it out, actually. If the method-r2i is != NULL, then the `do_ext_nconf` do not check (line 154) if the ctx is different from NULL when looking for ctx-db or ctx-db_meth. Shall it be checked as well ? An easy patch would be: if( (ctx) ( !ctx-db || !ctx-db_meth ) ) this would fix the segfault, actually... Later, Max Allan Clark wrote: I assume you compiled your libcrypto. You should probably build it -g to enable debug symbols which will let gdb tell you what file, line, and function it segv at Allan On 7/12/07, Massimiliano Pala [EMAIL PROTECTED] wrote: Hi all, I have been trying to encode some extensions and sometimes I get a segfault that I can not explain. The following code is the one causing the error: ret = X509V3_EXT_conf(NULL, NULL, name_s, valString); where: name_s = certificatePolicies valString = OID:1.3.6.1.4.1.65.1.1.1.1 by using gdb, I get the following: Program received signal SIGSEGV, Segmentation fault. 0x4b530940 in X509V3_EXT_i2d () from /lib/libcrypto.so.6 (gdb) backtrace #0 0x4b530940 in X509V3_EXT_i2d () from /lib/libcrypto.so.6 #1 0x4b530bd2 in X509V3_EXT_nconf () from /lib/libcrypto.so.6 #2 0x4b530c86 in X509V3_EXT_conf () from /lib/libcrypto.so.6 Do you have any idea of what's going on ? Later, Max -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Extension Encoding - segfault
Hi all, I have been trying to encode some extensions and sometimes I get a segfault that I can not explain. The following code is the one causing the error: ret = X509V3_EXT_conf(NULL, NULL, name_s, valString); where: name_s = certificatePolicies valString = OID:1.3.6.1.4.1.65.1.1.1.1 by using gdb, I get the following: Program received signal SIGSEGV, Segmentation fault. 0x4b530940 in X509V3_EXT_i2d () from /lib/libcrypto.so.6 (gdb) backtrace #0 0x4b530940 in X509V3_EXT_i2d () from /lib/libcrypto.so.6 #1 0x4b530bd2 in X509V3_EXT_nconf () from /lib/libcrypto.so.6 #2 0x4b530c86 in X509V3_EXT_conf () from /lib/libcrypto.so.6 Do you have any idea of what's going on ? Later, Max -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063Work Phone: +1 (603) 646-9179 --o smime.p7s Description: S/MIME Cryptographic Signature
Re: ERROR in openssl 0.9.8a: PRNG not seeded
Sundaram, Balaji (MSB) wrote: Hi all, We are migrating from openssl 0.9.7g to 0.9.8a. During this migration we are getting the following error. This error appears in Solaris 7 and HP-UX 11.0 platforms. But the same works in Solaris 8 and Linux platforms. In solaris 8, we found that /dev/random and /dev/urandom files exist. But in case of Solaris 7 these files are not Hi, go to http://www.sunfreeware.com/ - there you'll find needed patches for Solaris. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
CRL verification padding problems
Hello guys, I have a problem with X509 certificate and CRL checking. When using the X509_CRL_verify(crl, pkey) function (I get an error also by using the 'openssl crl -CAfile... ' command), I get the following Error: 7322:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: 7322:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:580: 7322:error:0D089006:asn1 encoding routines:ASN1_verify:EVP lib:a_verify.c:162: Anyway, separately both the certificate and the CRL seems to look good. If you have ideas I can send you the certificate and the CRL, I am not sending them to the list as them are quite big (~1.6Mb). Have a nice day, Byz! --- Massimiliano Pala ([EMAIL PROTECTED]) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRL verification padding problems
Dr. Stephen Henson wrote: [...] Check to see if the CRL has an authority key id and if so if it matches the subject key id of the CA you are using. If not then the problem is that the wong CA and hence wrong public key is being used to verify the CRL signature. You are right, unfortunately I have to deal with a PKI where multiple certs are issued to every SubCA -- all of them are valid at the same time, and issued to the same Subject, what changes is the Key and the keyUsage... a real mess... I guess no 'standard' client is capable of verifying correctly the CRLs as the certificate used to issue certs is not the same used to sign CRLs... rrrgghh! The problem was that :-( In my opinion the error reported 7322:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: 7322:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:580: 7322:error:0D089006:asn1 encoding routines:ASN1_verify:EVP lib:a_verify.c:162: should be changed as it is not really clear :-D Thank you again. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
ENGINE issues
Dear list,
I have a problem when integrating my application with
LunaSA/LunaCA3 by using the ENGINE extension with our
OpenCA-OCSP daemon.
I successfully can execute PRE and POST commands by using
`ENGINE_ctrl_cmd_string()' (e.g. CONF_PATH and login
commands).
The problem is that, by using default OpenSSL ENGINE
commands (with OpenSSL 0.9.7) to load the private key
generated on the LunaSA I get the following error:
---
30436:error:2609607D:engine
routines:ENGINE_load_private_key:no load
function:eng_pkey.c:110:
---
The code that generates the problem is the following:
---
ocspd_conf-ocspd_pkey =
ENGINE_load_private_key(ocspd_conf-engine,
keyfile, UI_OpenSSL(), cb_data);
if ( bio_out = BIO_new_fp( stderr, BIO_NOCLOSE)) {
ERR_print_errors( bio_out );
BIO_free(bio_out);
}
---
On the LunaSA device we have the following objects:
---
[EMAIL PROTECTED] root]# cmu list -display=id,label,handle
Please enter password for token in slot 1 :
id=0001 label=ocspPubKey handle=10
id=0001 label=ocspPrivKey handle=11
---
and in keyfile variable in the example I set the id of the
private key (0001).
Does anyone have experiences on how to load a private
key from the LunaSA (LunaCA3) with OpenSSL 0.9.7 ?
Thanks for any help,
--- Massimiliano Pala
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: ENGINE issues
On Thu, 13 Jan 2005 12:27:57 - David C. Partridge [EMAIL PROTECTED] wrote: IIRC the Luna CA3 is FIPS140-2 LEVEL 3 which means it won't allow you under nay circumstances to extract the private key from the device (non-extractable, sensitive in PKCS#11 parlance). What this means is that you need to send the data to the device to be signed (don't know how to do this using openssl), rather than extracting the key and using openssl to do the crypto in software. My intention was not to extract the key but to tell OpenSSL to use a particular key, thus I need a way to generate a reference to the key. I just taken as an example the code from openssl, but there is something I am doing wrong somewhere... All I want to do is to enable ENGINE so all crypto operations are performed on the LunaSA (and probably I am missing something important here :-( ) and to use the Key sored on the device, not a software one. Does anybody have experiences (also with other hardware) that may be of some help ??? Thank you, byz. --- Massimiliano Pala ([EMAIL PROTECTED]) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Fwd: RE : ENGINE issues
--- the forwarded message follows --- ---BeginMessage--- On Thu, 13 Jan 2005 16:26:33 +0100 Frédéric Donnat [EMAIL PROTECTED] wrote: Hi Massimo, Hi, As far as I know it you must LOAD (pre command I think) the ENGINE to correctly set all ENGINE function pointers... And thus initialize openssl with your ENGINE. Did you do it? Yes, init of the ENGINE works fine. You should be able to get a priovate key handle but not the private key paramters according to PKCS#11. I have done such thing with a Bull PKCS 11 module and their PKCS#11 patch and it works fine. You could try to trace Luna ENGINE in ENGINE_load_private_key() function in order to find the faulty part of code. This is what I have done... and I found that they simply did not implemented the ENGINE_load_private_key()... I am trying to implement it... but it is quite hard to do it in less than one day. I hope they will respond to my requests sending me the missing functions (also the ENGINE_load_public_key() is missing, but this is not an issue... at the moment!). It sounds really strange, anyway, that this function is missing... as this implies that no ENGINE support is there to use private keys directly on the LunaCA/SA!?!? Anyway if you have some code you can send me about your implementation, I would be glad to take a look at it in order to check my implementation. Thx, for your help. -- Massimiliano Pala ---End Message---
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Andreas M. Kirchwitz via RT wrote: Hi OpenSSL team! [...] OpenSSL 0.9.7d successfully completes the tests. (No wonder, test/evptests.txt doesn't contain AES-128-CFB1 stuff. ;-) Does it mean that OpenSSL is broken? Or does it mean that the test procedure is broken in this respect? Tests complete successfully on my test machines: - Linux box (Debian, Linux 2.4.27 SMP, 2 Xeon 3.2 Ghz CPU, gcc-3.0.4) - Linux box (RH 9, Linux 2.4.27#6 SMP i686 i686 i386 GNU/Linux, gcc-3.2.2-5) Probably another issue tied to Fedora ??? -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
Re: Adding a new Cipher
kentlinux wrote: [...] It is only for crypto I do not know anything about SSL Thank you, this is exaclty what I was looking for. When ready we will send the patch to add aes-ccm among the ciphers. Have a nice day! -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
Adding a new Cipher
Hello all, we are working to integrate a new cipher (aes-ccm) into the crypto lib. We want to have the new algorithm available from every application linking the library but we have not found where we have to add the cipher definition to have it listed among the available ones. Can you help us ??? Thank you in advance, have a nice day! -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
BIO, sockets and fork() problems
Hello all,
I am trying to implement a pre-spawned daemon and I have some problems with
the BIO_* socket.
The basic idea is this:
The father process sets up the bio, spawns 'n' processes. These processes
compete on a SEMAPHORE and if they get the lock they will BIO_do_accept(),
release the lock to the next child and take care of the communication with
the client.
Here it is the father setting up the accept BIO socket:
o SNAP o--
1BIO *bio_socket = NULL;
2BIO *buf_bio = NULL;
3
4/* Set buffered bio */
5buf_bio = BIO_new(BIO_f_buffer());
6if (!buf_bio) {
7... Error ...;
8}
9
10
11/* Bind to socket */
12if((bio_socket = BIO_new_accept( port )) == NULL ) {
13 ... Error ...;
14}
15
16BIO_set_accept_bios(bio_socket, buf_bio);
17if (BIO_do_accept(bio_socket) = 0)
18{
19 ... Error...;
20
21}
22
23return bio_socket;
o SNAP o--
Now the server spawns 'n' child processes. The code of the children is
the following:
o SNAP o--
1 /* Get the Lock - actually using SEMAPHORES */
2 while ( 1 ) {
3if( (got_lock = get_lock( ocspd_conf )) == 0 ) {
4... Error ...;
5break;
6}
7
8 if (BIO_do_accept( bio_socket ) = 0) {
9... Error ...;
10}
11
12if( (curr_bio = BIO_pop( bio_socket )) == NULL ) {
13... Error ...;
14}
15
16 /* Now release the lock so that other children can
17 compete on the lock and accept new connections */
18 if( (got_lock = lease_lock( ocspd_conf )) == 0 ) {
19...Error...;
20}
21
22 /* Get input data from the bio */
23if((req = get_request( curr_bio )) == NULL ) {
24...Error...;
25}
26
27 /* Make and send the response */
28 if(( make_ocsp_response(resp, req)) == 0 ) {
29... Error ...;
30}
31send_response( curr_bio, resp );
32
33 /* Free the BIO */
34 BIO_free_all( curr_bio );
35 }
o SNAP o--
Everything seems to work fine, but the problem is that the connection is
not closed and I get hanging connection waiting while the client already
disconnected - as reported by 'netstat -an':
tcp0 0 0.0.0.0:25600.0.0.0:* LISTEN
tcp0 0 130.192.1.59:2560 130.192.1.59:35490 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35491 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35488 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35489 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35494 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35492 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35493 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35480 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35486 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35487 TIME_WAIT
tcp0 0 130.192.1.59:2560 130.192.1.59:35485 TIME_WAIT
The first is the server (bio_socket) while the others are pending connections
(curr_bio). How to avoid this problem ???
I have also tried using 'BIO_free(curr_bio)' at line 34 (last snap), but then
the BIO_do_accept() hangs the next cycle.
Someone has faced the same problem ? How to solve it ? Are there some flags I
have to set when setting up the BIOs ? Do I have to flush/reset (how ???) the
'buf_bio' (line 16 of the first snap) before calling the BIO_free_all()?
Thanks in advance for the help.
Have a nice day!
--
Best Regards,
Massimiliano Pala
--o
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
Tel.: +39 (0)11 564 7081
http://security.polito.it Fax:+39 178 270 2077
Mobile: +39 (0)347 7222 365
Politecnico di Torino (EuroPKI)
Certification Authority Informations:
Authority Access Point http://ca.polito.it
Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List: http://ca.polito.it/crl02/crl.crl
--o
smime.p7s
Description: S/MIME Cryptographic Signature
Re: OCSP and ENGINE
Dr. Stephen Henson wrote: Yout don't need to do anything special. You just have to get the relevant EVP_PKEY from the ENGINE and pass it to the relevant APIs for OCSP. The rest is automatic if the ENGINE has been written properly. Good. Just one question, is there a method to get the EVP_PKEY using standard (ENGINE) functions or does it depend on the implemented engine ? At the moment I have a LunaSA but I want the server to be able to use different ENGINE sharing as much code as possible. Thanks for the help. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
OCSP and ENGINE
Hello, I want to use the OCSP routines with an HSM to provide a high number of signed responses per second. What do I have to do in order to have my application to use the ENGINE extension with OCSP commands/libraries ? I have this doubt mainly because I am not an ENGINE expert and partially because I have not found any reference to the ENGINE extension in the OCSP code. Please let me know. -- Best Regards, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)11 564 7081 http://security.polito.it Fax:+39 178 270 2077 Mobile: +39 (0)347 7222 365 Politecnico di Torino (EuroPKI) Certification Authority Informations: Authority Access Point http://ca.polito.it Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html Certificate Revocation List: http://ca.polito.it/crl02/crl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
OpenVMS 8.1 (Eval)
Hi Guys, we are currently working on this platform - OpenVMS 8.1, Itanium2 - is this OS/CPU supported by openssl ? -- C'you, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.org Fax:+39 178 270 2077 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 University of Modena and Reggio Emilia Certification Authority Informations: Authority Access Point http://pki.unimo.it Authority's Certificate:http://pki.unimo.it/ca/issuers.html Certificate Revocation List: http://pki.unimo.it/crl/cacrl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #839] Patch pk7_lib.c:PKCS7_get_recip_info()
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #839] Patch pk7_lib.c:PKCS7_get_recip_info() [2]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509v3 extensions (repost)
Rich Salz wrote: Critical means if you don't know what this means, you cannot process the cert. or am i suffering from too many late nights hacking? You are right. This is the reason why setting the CRITICAL bit could lead to some interoperability issues, therefore you should think twice before setting it :-D -- C'you, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.org Fax:+39 178 270 2077 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 University of Modena and Reggio Emilia Certification Authority Informations: Authority Access Point http://pki.unimo.it Authority's Certificate:http://pki.unimo.it/ca/issuers.html Certificate Revocation List: http://pki.unimo.it/crl/cacrl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
ASK OPENSSL: CRL extensions
Hi all,
I have one question for you. I want to check extensions added to a CRL
entry but I do not know how to access informations. Actually I use the
code:
rev = X509_CRL_get_REVOKED(crl);
for(i = 0; i sk_X509_REVOKED_num(rev); i++) {
r = sk_X509_REVOKED_value(rev, i);
for (i=0; isk_X509_EXTENSION_num(r-extensions); i++)
{
ASN1_OBJECT *obj;
ASN1_OBJECT *obj_tmp;
X509_EXTENSION *ex;
ex=sk_X509_EXTENSION_value(r-extensions, i);
obj=X509_EXTENSION_get_object(ex);
[ Missing Code ]
}
I would like in the [ Missing Code ] to check the object (that is of
the NID_crl_reason type) for its value, for example if it is a
certificateHold or RemoveFromCRL, etc...
What's the correct way to do it ?
Thanks to all of you...
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
Tel.: +39 (0)59 270 094
http://www.openca.orgFax:+39 178 221 8225
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [openssl.org #438] SCEP
Richard Levitte via RT wrote: Oh look, there's a draft too: http://www.ietf.org/internet-drafts/draft-nourse-scep-06.txt This is the draft I used as a reference to implement SCEP... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.orgFax:+39 178 221 8225 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #438] SCEP support
Dear Dr. Henson, forgive my ignorance but I am not at ease with your methods. You assigned me this number but what about your impression about the SCEP support integrated into OpenSSL ? I hope you are for it, but am not sure what I have to do now. Do I have to do all the integration work by myself and post it as a patch against the 0.9.7 or can we discuss of the work (i.e. I have the code almost working as a standalone command, but I guess the best integration method could be having a new scep directory within the crypto one and the scep.c in the apps directory) and where to put the code ? Let me know. Thanks for your time. -- Best Regards, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.orgFax:+39 178 221 8225 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #438] SCEP
Hi, its been quite a while since we heard last time, I hope you remember me. I have (quite) ended support for the SCEP messages for our project and I think it could be a useful addon to OpenSSL. The code is quite clean and could be added to the command line utility as 'openssl scep .. '. What do you think about it ? As integrating the work into OpenSSL will require some additional work I would like to know if you were interested in it before cleaning up the code. Let me know. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.orgFax:+39 178 221 8225 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a pkcs7 structure
Vadim Fedukovich wrote: [...] It's easy to see PKCS7_decrypt() does X509_check_private_key(certificate, key) and then PKCS7_dataDecode() One could also read PKCS7_dataDecode() source to see decryption certificate will only be used to match issuer and serial number with that of each recipient info from enveloped data, so your code should work fine with PKCS7_decrypt() replaced Indeed I had tried also using directly the PKCS7_dataDecode() but I got a core dump as well... Thanks for the hint on the PKCS7_decrypt(), however should't we add some checking on the passed parameters so as to avoid unsafe code from core dumping ? -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Problem decrypting a pkcs7 structure
Hi,
I am trying to decrypt some data in a pkcs7 env structure. The problem comes
when I try to use the PKCS7_decrypt (I guess the problem to be in
PKCS_dataDecode that is actually called -- see pk7_doit.c and pk7_smime.c).
If I use a loaded normal certificate everything is fine, but when I try
to use a fake X509 structure where I store only the cert_info-issuer
and cert_info-serialNumber data (the only one that should be accessed
in the used when decrypting) I get a core dump.
Here it is the code:
if( (foo_cert = X509_new()) == NULL ) {
// Memory error...
} else {
char buffer[1024];
foo_cert-cert_info-issuer =
rinfo-ias-issuer;
foo_cert-cert_info-serialNumber =
rinfo-ias-serial;
}
bio = BIO_new(BIO_s_mem());
if (PKCS7_decrypt(p7, pkey, foo_cert, bio, 0) == 0) {
BIO_printf(bio_err, %s:%d: decryption failed\n, __FILE__,
__LINE__);
goto err;
}
Where am I wrong ? Is there a function for decrypting a pkcs7 structure
that does not require a (X509 *) [virtually useless, if not for cecking
against the recipient info, I guess] ?
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.orgTel.: +39 (0)59 270 094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [openssl.org #323] Bug in authorityKeyIdentifier extension?
Frédéric Giudicelli via RT wrote: Well Microsoft support tells me it's openssl's fault, and you tell me it's microsoft's ? It's dead end, what am I supposed to tell my clients ? Well... altough PKIX recommends the use of the authorityKeyId, and that the French Government says you must to have this extension, to be certified, I'll have to remove this extension ? No, I agree with Richard's opionion, and I guess it is the only one that makes sense... anyway M$ has been often reported to not follow the standards nevertheless what they where saying about it. My suggestion, do things in the right way. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem decrypting a pkcs7 structure
Hi all,
I am replying myself... this seems like a sign I have to stop working
late at night... anyway... here it comes the real message...
Massimiliano Pala wrote:
Hi,
I am trying to decrypt some data in a pkcs7 env structure. The problem
comes
when I try to use the PKCS7_decrypt (I guess the problem to be in
PKCS_dataDecode that is actually called -- see pk7_doit.c and pk7_smime.c).
If I use a loaded normal certificate everything is fine, but when I try
to use a fake X509 structure where I store only the cert_info-issuer
and cert_info-serialNumber data (the only one that should be accessed
in the used when decrypting) I get a core dump.
Here it is the code:
if( (foo_cert = X509_new()) == NULL ) {
// Memory error...
} else {
char buffer[1024];
foo_cert-cert_info-issuer =
rinfo-ias-issuer;
foo_cert-cert_info-serialNumber =
rinfo-ias-serial;
}
bio = BIO_new(BIO_s_mem());
if (PKCS7_decrypt(p7, pkey, foo_cert, bio, 0) == 0) {
BIO_printf(bio_err, %s:%d: decryption failed\n, __FILE__,
__LINE__);
goto err;
}
Where am I wrong ? Is there a function for decrypting a pkcs7 structure
that does not require a (X509 *) [virtually useless, if not for cecking
against the recipient info, I guess] ?
Still I don't know where and why, but it seems that in the fake X509
there should be a pkey, so I made with the one I had... :-D this code
fixes the problem (after the X509_new()), but if you know why the old
one was not working, please let me know ...
X509_set_issuer_name(foo_cert,rinfo-ias-issuer);
X509_set_subject_name(foo_cert,rinfo-ias-issuer);
X509_set_serialNumber(foo_cert,rinfo-ias-serial);
// X509_gmtime_adj(X509_get_notBefore(foo_cert),0);
// X509_gmtime_adj(X509_get_notAfter(foo_cert), 1L );
X509_set_pubkey(foo_cert, pkey);
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.orgTel.: +39 (0)59 270 094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
smime.p7s
Description: S/MIME Cryptographic Signature
OpenSSL ENGINE, OpenCA MUSCLE
Hi, I have planned to write some code to implement an ENGINE allowing OpenSSL to use the MUSCLEcard framework so as to use SmartCards just as the other HW tokens (it could be useful in our project to use the CA keys on a Smart Card rather then on the HardDrive and having to protect a whole computer instead of a little piece of plastic ). I am planning to code it for the openssl-0.9.7-beta3 ( is it better working on latest openssl-0.9.7-stable SNAPs ? ). This work will allow, that's our goal, to use the openssl together with any MUSCLE's supported SC and reader. Also it will be possible to use their pkcs11 module already shipping with their project. We plan to use this to support CA's keys directly on SC with crypto features ( such as cryptoFlex, CyberFlex, etc... ). Let me know if some work has been already made by someone and if we can cooperate in this work. Also I'd like to know if it will be best to code this ENGINE as a dynamic one (external to the OpenSSL source tree) or it is best we start coding it directly into OpenSSL ? -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL ENGINE, OpenCA MUSCLE
Richard Levitte - VMS Whacker wrote: I would suggest, to make it easier, that you go for the MuscleCard API for now. There will be a generic PKCS#11 engine at some point, and that should then be possible to use as well. That is my point of view, either. So I guess I will start studying the implementation for the MuscleCard API so as to have some code ready soon, we'll see what to do next later on... :-D Anyone has suggestions about the project ? -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL ENGINE, OpenCA MUSCLE
Richard Levitte - VMS Whacker wrote: madwolf If you look at one of the built-in engines, you'll see that they're [...] madwolf required, I will build a separate package too... It's good enough to build it in crypto/engine. But note that for 0.9.8-dev, there's a move to having all the hardware interface being built as shared libraries, and in a separate directory. It's possible that we'll have a separate repository of engines in the future... Ok, I hope that not much code rewriting will be required for the 0.9.8 version (if any). I am starting to take a look at the README for the ENGINE... well I guess it will require more time than what I had expected and I am even not sure it will be possible doing what I was intended to do without having at least the ca command enhanced... ... but I have only read it fast and I am probably wrong ... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Re: SQL DB instead of index.txt
Dr S N Henson wrote:
[...]
saying it doesn't understand the method. This maps well to the ASN1
CHOICE type which is represented as:
struct {
int type;
union {
TYPE1 *a;
TYPE2 *b;
TYPE3 *c;
/* etc */
} d;
}
Hi,
I have not followed the discussion from the beginning, but have you
considered supporting BerkeleyDB ? We have, for our project, two
different modules one supporting SQL DBMS and the other using
BerkeleyDB as backend (one can choose what he likes best for his
own system). I suggest you to fist implement the simplest (for
the user point of view) that, to me, is the BerkeleyDB (or similar,
we use this because it is fast, reliable and os... ) and then
add support for SQL DBMS (more complex to administrate).
If this point have already been discussed, just ignore my mail
and forgive me for the additional noise...
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager] madwolf at cpan.org
madwolf at openca.org
http://www.openca.org madwolf at hackmasters.net
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
smime.p7s
Description: S/MIME Cryptographic Signature
Patch for req.c (+docs/apps/req.pod)
Hi,
this patch allows for public key structure retrivial when using the
'req' command. Following are the details:
Added Switch:
o -pubkeyoutput public key
Fixes:
o printing of using config file... only if -verbose is used
Comments:
The patch is indeed very simple and adds just the possiblity to
have the public key printed out.
Let me know about the status of this patch, thanks.
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.orgTel.: +39 (0)59 270 094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
--- req.c Fri Nov 2 15:00:10 2001
+++ req.c.mod Thu Nov 22 18:43:05 2001
@@ -106,6 +106,7 @@
* -rand file(s) - load the file(s) into the PRNG.
* -newkey - make a key and a request.
* -modulus- print RSA modulus.
+ * -pubkey - print Public Key.
* -x509 - output a self signed X509 structure instead.
* -asn1-kludge- output new certificate request in a format that some CA's
* require. This format is wrong
@@ -159,7 +160,7 @@
long newkey = -1;
BIO *in=NULL,*out=NULL;
int informat,outformat,verify=0,noout=0,text=0,keyform=FORMAT_PEM;
- int nodes=0,kludge=0,newhdr=0,subject=0;
+ int nodes=0,kludge=0,newhdr=0,subject=0,pubkey=0;
char *infile,*outfile,*prog,*keyfile=NULL,*template=NULL,*keyout=NULL;
char *engine=NULL;
char *extensions = NULL;
@@ -218,6 +219,10 @@
if (--argc 1) goto bad;
keyfile= *(++argv);
}
+ else if (strcmp(*argv,-pubkey) == 0)
+ {
+ pubkey=1;
+ }
else if (strcmp(*argv,-new) == 0)
{
newreq=1;
@@ -412,6 +417,7 @@
BIO_printf(bio_err, -in arginput file\n);
BIO_printf(bio_err, -out arg output file\n);
BIO_printf(bio_err, -text text form of request\n);
+ BIO_printf(bio_err, -pubkeyoutput public key\n);
BIO_printf(bio_err, -noout do not output REQ\n);
BIO_printf(bio_err, -verifyverify signature on REQ\n);
BIO_printf(bio_err, -modulus RSA modulus\n);
@@ -473,7 +479,8 @@
{
long errline;
- BIO_printf(bio_err,Using configuration from %s\n,template);
+ if( verbose )
+ BIO_printf(bio_err,Using configuration from %s\n,template);
req_conf=NCONF_new(NULL);
i=NCONF_load(req_conf,template,errline);
if (i == 0)
@@ -485,7 +492,8 @@
else
{
req_conf=config;
- BIO_printf(bio_err,Using configuration from %s\n,
+ if( verbose )
+ BIO_printf(bio_err,Using configuration from %s\n,
default_config_file);
if (req_conf == NULL)
{
@@ -922,7 +930,7 @@
BIO_printf(bio_err,verify OK\n);
}
- if (noout !text !modulus !subject)
+ if (noout !text !modulus !subject !pubkey)
{
ex=0;
goto end;
@@ -949,6 +957,20 @@
perror(outfile);
goto end;
}
+ }
+
+ if (pubkey)
+ {
+ EVP_PKEY *pkey;
+ pkey=pkey=X509_REQ_get_pubkey(req);
+ if (pkey == NULL)
+ {
+ BIO_printf(bio_err,Error getting public key\n);
+ ERR_print_errors(bio_err);
+ goto end;
+ }
+ PEM_write_bio_PUBKEY( out, pkey);
+ EVP_PKEY_free(pkey);
}
if (text)
--- req.pod Thu Nov 22 18:38:33 2001
+++ req.pod.mod Thu Nov 22 18:38:14 2001
@@ -15,6 +15,7 @@
[B-out filename]
[B-passout arg]
[B-text]
+[B-pubkey]
[B-noout]
[B-verify]
[B-modulus]
@@ -86,6 +87,10 @@
=item B-text
prints out the certificate request in text form.
+
+=item B-pubkey
+
+prints out the public key structure.
=item B-noout
smime.p7s
Description: S/MIME Cryptographic Signature
Re: HOWTO renew a certificate
Franck Martin wrote: I'm writing an SSL Certificate HOWTO, that I will submit to the LDP. [...] I want to know the procedure to renew a certificate with OpenSSL. It seems there is a bug in openSSL has it does not want to sign again a request certificate if the DN is already inside the Certifcate Database. AFAIK this is not a bug but a feature (?). This prevents from having more valid ceritificates with the same DN. This should be avoided as reported in RFCs, anyway it is a common practice in most PKIs. To renew a certificate you'll have either to: 1. Revoke it before issuing the new certificate; 2. Hacking the index.txt file changing the status of the certificate from 'V' to 'E' and adding a valid expiration date; However keep in mind that certificate renewal (issuing a new certificate to the same subject using the same key) should be discouraged as its lifetime (key's one) should be considered ended with the expiration of the certificate (or you could have issued the certificate with a longer validity period, don't you think ?), at least to me. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Re: BUG: openssl pkcs12 segmentation fault on Linux
Massimiliano Pala wrote:
I'll try to be more specific in my next report.
Here I am again. The problem is very strange... indeed I find it difficult
to fix because I can simply not understand why the problem exists... Let's
see it:
1. The sk_PKCS7_new_null() is called by pkcs12.c at line 547.
2. The macro SKM_sk_new_null(PKCS7) is invoked.
--- from crypto/stack/safestack.h ---
#define SKM_sk_new_null(type) \
((STACK_OF(type) * (*)(void))sk_new_null)()
3. The function sk_new_null() is invoked.
--- from crypto/stack/stack.c
STACK *sk_new_null(void)
{
return sk_new((int (*)(const char * const *, const char * const *))0);
}
4. The function sk_new() is invoked. [ indeed I find it difficult to understand
the function definition, someone can explain it to me -- forgive my ignorance
]
5. The function sk_new returns successfully. The ret is correctly allocated
(STACK *) and initiated. The return(ret) is correctly reached.
6. Segmentation fault.
Why ??? The function succed when called before, like at line 469 (same macro
usage):
bags = sk_PKCS12_SAFEBAG_new_null ();
Hey... I tried, just now while writing the e-mail, to comment the call (line
539):
sk_PKCS12_SAFEBAG_pop_free(bags, PKCS12_SAFEBAG_free);
(just few lines up the 547) and found the coredump to happen at the line 556:
p8 = EVP_PKEY2PKCS8 (key);
so the line 547 does not segfault (as it should be...).
What's happening here ?!?! Someone has any idea ???
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.orgTel.: +39 (0)59 270 094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
S/MIME Cryptographic Signature
Re: BUG: openssl pkcs12 segmentation fault on Linux
Hi all. Just few lines to say that the bug (pkcs12 segfault on linux) seems to have been fixed in new openssl-SNAP-20011106. Thanks. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
Re: ca.c fix [-noemailDN]
Dr S N Henson wrote: I noticed these when I was attempting a different patch. I think the fix I've done is functionally equivalent to your patch, except it doesn't delete the email_dn option from do_subject() which I'll commit separately. Thanks. Also I've deleted emailAddress from the DN in a different way: dup the name then delete and emailAddress entries, this should retain the X509_NAME structure in the event of multi values AVAs being used. I was thinking of changing the patch to match that behaviour too :-D Thanks again... Did you had the chance of reading my comments in the email OpenSSL and Patches for CAs ? What do you think about it ? -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
ca.c fix [-noemailDN]
Hi,
I found 2 bugs in the previous patch, so here them are the fixes against
latest SNAP (20011026).
Poblems:
1. the dn_subject structure was not freed at the end of
the do_body function;
2. the dn_subject was not set (empty) if email_dn was set to 1.
This caused the entry in the index.txt file to report null DN
set.
To apply the patchm simply copy it into the openssl/apps dir and do the
following:
$ patch ca.c.fix-20011026
This will fix the bugs listed.
--
C'you,
Massimiliano Pala
--o-
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.orgTel.: +39 (0)59 270 094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365
--- ca.cThu Oct 25 11:00:26 2001
+++ ca.c.newSat Oct 27 18:51:09 2001
@@ -238,7 +238,7 @@
int verbose, X509_REQ *req, char *ext_sect, CONF *conf,
unsigned long certopt, unsigned long nameopt, int default_op,
int ext_copy);
-static X509_NAME *do_subject(char *subject, int email_dn);
+static X509_NAME *do_subject(char *subject);
static int do_revoke(X509 *x509, TXT_DB *db, int ext, char *extval);
static int get_certificate_status(const char *ser_status, TXT_DB *db);
static int do_updatedb(TXT_DB *db);
@@ -1859,7 +1859,7 @@
if (subj)
{
- X509_NAME *n = do_subject(subj, email_dn);
+ X509_NAME *n = do_subject(subj);
if (!n)
{
@@ -2071,6 +2071,11 @@
}
}
}
+ else
+ {
+ dn_subject=X509_NAME_dup(subject);
+ if(dn_subject == NULL) goto err;
+ }
row[DB_name]=X509_NAME_oneline(dn_subject,NULL,0);
row[DB_serial]=BN_bn2hex(serial);
@@ -2325,6 +2330,8 @@
if (CAname != NULL)
X509_NAME_free(CAname);
+ if (dn_subject != NULL)
+ X509_NAME_free(dn_subject);
if (subject != NULL)
X509_NAME_free(subject);
if (tmptm != NULL)
@@ -2992,7 +2999,7 @@
return ret;
}
-static X509_NAME *do_subject(char *subject, int email_dn)
+static X509_NAME *do_subject(char *subject)
{
X509_NAME *n = NULL;
@@ -3040,9 +3047,6 @@
BIO_printf(bio_err, No value provided for Subject Attribute
%s, skipped\n, ne_name);
continue;
}
-
- if ((nid == NID_pkcs9_emailAddress) (email_dn == 0))
- continue;
if (!X509_NAME_add_entry_by_NID(n, nid, MBSTRING_ASC, (unsigned
char*)ne_value, -1,-1,0))
{
S/MIME Cryptographic Signature
OpenSSL and Patches for CAs
Hi all, I am ri-posting this message as I have received no replies to it. If no one is interested in the proposals then simply ignore this message. ----- [ openssl ca command improve ] Some work could be initially done by introducing another switch (and conf keyword) to enable/disable the usage of the index.txt backend during certificate issuing -- this would enable using ca command with unsupported certificate profiles (such as duplicate DNs). Then, with patience, it should be a good thing starting a rewriting of the backend db support ... and then, only then, we could start adding new RFCs supported certificate profiles (empty DNs, etc... )... This is a quite big work to be done. I am not sure but I think it can be done without backward compatibility issues rising... [ libca development ] Another idea worth exploring could be the writing of a libca where ca functions are held as most of them are getting quite big and important and having in one large ca.c should be avoided. I am not sure this is the scope of the openssl project but as this lib will be strictly tied with openssl library itself it could be useful having it together with the package. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 --- ca.pod Mon Oct 22 19:20:50 2001 +++ ca.pod.new Mon Oct 22 19:20:25 2001 @@ -34,6 +34,7 @@ [B-spkac file] [B-ss_cert file] [B-preserveDN] +[B-noemailDN] [B-batch] [B-msie_hack] [B-extensions section] @@ -157,6 +158,16 @@ older IE enrollment control which would only accept certificates if their DNs match the order of the request. This is not needed for Xenroll. +=item B-noemailDN + +The DN of a certificate can contain the EMAIL field if present in the +request DN, however it is good policy just having the e-mail set into +the altName extension of the certificate. When this option is set the +EMAIL field is removed from the certificate' subject and set only in +the, eventually present, extensions. The Bemail_in_dn keyword can be +used in the configuration file to enable this behaviour. + +=item B-batch =item B-batch this sets the batch mode. In this mode no questions will be asked @@ -437,6 +448,7 @@ default_md = md5 # md to use policy = policy_any# default policy + email_in_dn= no# Don't add the email into cert DN nameopt = default_ca# Subject name display option certopt = default_ca# Certificate display option @@ -518,8 +530,11 @@ BCA.pl help a little but not very much. Any fields in a request that are not present in a policy are silently -deleted. This does not happen if the B-preserveDN option is used. -The behaviour should be more friendly and configurable. +deleted. This does not happen if the B-preserveDN option is used. To +enforce the absence of the EMAIL field within the DN, as suggested by +RFCs, regardless the contents of the request' subject the B-noemailDN +option can be used. The behaviour should be more friendly and +configurable. Cancelling some commands by refusing to certify a certificate can create an empty file. S/MIME Cryptographic Signature
Re: Cross Certification
Ravi Prakash B.V. wrote: Dear All, I do not receive any reply for this. Any pointers will be appreciated. Ravi Prakash B.V. Ravi Prakash B.V. wrote: Dear all, I want to establish cross certification between two different independent CAs. How is it possible? Any pointers/links/docs for the above. I really don't have experience in cross certification and I don't think there is some software supporting it, anyway the theory should be to sign each of the certificates with the one of the other CA... I am sorry but I could not remember if there (and in the case where) are reference to cross certification into RFCs... you could try to take a look into rfc2510, but I am not sure... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
Re: Patches for OpenSSL
Bodo Moeller wrote: Do you prefer the patch against the pre-patched version or against the patched version of the ca.pod file ? I'd prefer one for the patched version (but it shouldn't really matter if you use a context or unified diff). Here it is. I think it should be error free, anyway if you have time check it before submission (:-D). I don't think anyone has plans for that currently. If large-impact changes are needed, this should be discussed on openssl-dev. Yes, I know. I have to check. Some work could be initially done by introducing another switch (and conf keyword) to enable/disable the usage of the index.txt backend during certificate issuing -- this would enable using ca command with unsupported certificate profiles (such as duplicate DNs). Then, with patience, it should be a good thing starting a rewriting of the backend db support ... and then, only then, we could start adding new RFCs supported certificate profiles... This is a quite big work to be done and I am not sure it can be done without backward compatibility issues rising... Another idea worth exploring could be the writing of a libca where ca functions are held but I am not sure this is the scope of the openssl project... anyway as this is strictly tied with openssl library itself it could be useful having it together with the package. I will forward this e-mail to the openssl-dev mailing list also to get the feeling about all this stuff. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 --- ca.pod Mon Oct 22 19:20:50 2001 +++ ca.pod.new Mon Oct 22 19:20:25 2001 @@ -34,6 +34,7 @@ [B-spkac file] [B-ss_cert file] [B-preserveDN] +[B-noemailDN] [B-batch] [B-msie_hack] [B-extensions section] @@ -157,6 +158,16 @@ older IE enrollment control which would only accept certificates if their DNs match the order of the request. This is not needed for Xenroll. +=item B-noemailDN + +The DN of a certificate can contain the EMAIL field if present in the +request DN, however it is good policy just having the e-mail set into +the altName extension of the certificate. When this option is set the +EMAIL field is removed from the certificate' subject and set only in +the, eventually present, extensions. The Bemail_in_dn keyword can be +used in the configuration file to enable this behaviour. + +=item B-batch =item B-batch this sets the batch mode. In this mode no questions will be asked @@ -437,6 +448,7 @@ default_md = md5 # md to use policy = policy_any# default policy + email_in_dn= no# Don't add the email into cert DN nameopt = default_ca# Subject name display option certopt = default_ca# Certificate display option @@ -518,8 +530,11 @@ BCA.pl help a little but not very much. Any fields in a request that are not present in a policy are silently -deleted. This does not happen if the B-preserveDN option is used. -The behaviour should be more friendly and configurable. +deleted. This does not happen if the B-preserveDN option is used. To +enforce the absence of the EMAIL field within the DN, as suggested by +RFCs, regardless the contents of the request' subject the B-noemailDN +option can be used. The behaviour should be more friendly and +configurable. Cancelling some commands by refusing to certify a certificate can create an empty file. S/MIME Cryptographic Signature
Re: Patches for OpenSSL [EMAIL in DN]
Harald Koch wrote: There's a configuration option in the openssl.conf file that lets you either copy or move the email address from the X509 subject to the subjectAltName extension. The problem was that if you did not wanted the EMAIL field in the subject while having the extensions correctly set you should use the $ENV support for it to be set (I know of any other methods useful when issuing certs as the email is one field that changes for every certificate and it is not recomended to edit the config file each new certificate :-D ). I think this patch is useful at least when dealing with SPKAC and PKCS#10 (not IE, I suppose it has some problem importing certificates with DN different from the one submitted in the req) requests -- gives you the chance not to change the code you already have for certificate requesting, also could help enforcing a correct policy within your CA. At least to me... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 smime.p7s Description: S/MIME Cryptographic Signature
Patches for OpenSSL [EMAIL in DN]
Hi, It's been some time since I wrote last time on the mailing lists (:-D), anyway I have some patches for the ca.c command. This time them should be complete (the ca.pod patch is present also). To patch simply copy the ca.patch in the apps/ dir and the ca.pod.patch in the docs/apps and do: $ cd apps $ patch ca.patch $ cd ../doc/apps $ patch ca.pod.patch [just to be complete :-D ] Please let me know your opinion. P.S.: Actually I get a core dump on the SNAP (20011013) independently from my patch (so I use it together with an old SNAP that works - 20010826) when using many commands as req, ca, etc... Now it comes the real stuff. DESCRIPTION === This patch adds the possibility to not include the EMAIL field in the DN of the issued certificate when issuing a new certificate. This was needed as the inclusion of the EMAIL is actually deprecated by RFCs. This patch does not alter the normal behaviour of the ca command if the flag or the config keyword is not used. The added flag reads as follows: -noemailDN - Don't add the EMAIL field into certificate' subject command line samples usage: openssl ca -spkac spkac.req -cert cacert.pem -keyfile cakey.pem \ -config conf/openssl/openssl.cnf -noemailDN -preserveDN openssl ca -in req.pem -noemailDN -cert cacert.pem -keyfile cakey.pem \ -config conf/openssl/openssl.cnf The added configuration key is email_in_dn and if set to no the EMAIL field is not added to the certificate' subject (equivalent to the usage of the -noemailDN command line switch). The command line option overrides the configuration file's value. sample configuration keyword usage: ... oid_file= $dir/private/.oid x509_extensions = user_cert # The extentions to add to the cert email_in_dn = no# Don't add the email into the cert DN ... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 --- ca.cTue Oct 16 00:46:06 2001 +++ ca.new Tue Oct 16 00:45:41 2001 @@ -126,6 +126,7 @@ #define ENV_DEFAULT_CRL_DAYS default_crl_days #define ENV_DEFAULT_CRL_HOURS default_crl_hours #define ENV_DEFAULT_MD default_md +#define ENV_DEFAULT_EMAIL_DN email_in_dn #define ENV_PRESERVE preserve #define ENV_POLICY policy #define ENV_EXTENSIONS x509_extensions @@ -182,6 +183,7 @@ -spkac file - File contains DN and signed public key and challenge\n, -ss_cert file - File contains a self signed cert to sign\n, -preserveDN - Don't re-order the DN\n, + -noemailDN - Don't add the EMAIL field into certificate' subject\n, -batch - Don't ask questions\n, -msie_hack - msie modifications to handle all those universal strings\n, -revoke file- Revoke a certificate (given in file)\n, @@ -211,32 +213,32 @@ static int save_serial(char *serialfile, BIGNUM *serial); static int certify(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy,TXT_DB *db, - BIGNUM *serial, char *subj, char *startdate,char *enddate, - long days, int batch, char *ext_sect, CONF *conf,int verbose, - unsigned long certopt, unsigned long nameopt, int default_op, - int ext_copy); + BIGNUM *serial, char *subj, int email_dn, char *startdate, + char *enddate, long days, int batch, char *ext_sect, CONF *conf, + int verbose, unsigned long certopt, unsigned long nameopt, + int default_op, int ext_copy); static int certify_cert(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy, - TXT_DB *db, BIGNUM *serial, char *subj, char *startdate, - char *enddate, long days, int batch, char *ext_sect, - CONF *conf,int verbose, unsigned long certopt, + TXT_DB *db, BIGNUM *serial, char *subj, int email_dn, + char *startdate, char *enddate, long days, int batch, + char *ext_sect, CONF *conf,int verbose, unsigned long certopt, unsigned long nameopt, int default_op, int ext_copy, ENGINE *e); static int certify_spkac(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy, -TXT_DB *db
Re: OCSP daemon
Hi, I also develop an OCSP responder and I'm interested to find the ocsp deamon. Is it in Openssl or OpenCA ? It is OpenCA although it is mostly based on the OpenSSL support for OCSP. Indeed I was thinking about having it as an Apache Modules so as to have all the HTTP code and most of the server related issues already addressed... -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
openssl req ( -passin env:pwd ) FIX
Hi, the fix for the bug is very simple, the error seems at line 596 where the load_key misses the passin parameters: pkey = load_key(bio_err, keyfile, keyform, NULL, e, Private Key); to correct the bug simply substitute the NULL with the passin variable: pkey = load_key(bio_err, keyfile, keyform, passin, e, Private Key); Hope this is the right way to cerrect the bug. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
openssl req BUG ( -passin env:pwd ignored)
Hi, I found a probable bug in openssl req command (SNAP 20010822). When I use the following command: $ pwd=passwd /usr/bin/openssl req -passin env:pwd -new \ -config openssl.cnf -subj [EMAIL PROTECTED], ..., C=IT \ -out careq.pem -key cakey.pem instead of generating the request without requiring the password (in the pwd env variable) it still asks for it from the standard input. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
Re: OCSP daemon
Dr S N Henson wrote: I managed the ocspd server to respond to the psm, anyway I get an error into the HTTP reported format by psm. I don't know if this is related to the response itself (and the reported error is not specific for the response) or is a simple error in the HTTP syntax. Here is what I send out BEFORE sending the DER encoded response: HTTP/1.0 200 OK Content-type: application/ocsp-response Content-Length: 410 And then follows the response. Some hint on OCSP support into netscape and mozilla: o All requests are Version 1 (0x0); o Netscape PSM is capable of requesting to ports different from the 80 while Mozilla does not correctly read the URL and uses only Port 80; o Mozilla verifies all certificates when using the prefs/security../manage certificates option while Netscape PSM let you verify each certificate separately; More tests needed, anyway. Just a question about OCSP responders available: someone has some URL for testing proposes ? If someone is interested in seeing a very ugly piece of code (just testing, needs major work...) I hope I will manage to put it onto the web within tomorrow at OpenCA (guess the module name ... OpenCA-OCSPD ). -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ca Problems
Dr S N Henson wrote: Can you give some more information about what you've actually modified? I have scheduled submission with Bodo by the end of this week as he is very busy at the moment... Or is it possible to get this behaviour with the standard 'ca' utility? If so, how? Yes it happens when the DN order is like this: [EMAIL PROTECTED], CN=Mad Max, OU=myOu, O=org, C=IT While if I have a DN like this: C=IT, O=org, OU=myOU, CN=Mad Max, [EMAIL PROTECTED] I get valid email in the subjectAltName. It seems like it is tied to the ext adding code, but I am not sure... Wait... I have made some othe DNs trying and it seems that if I put the Email=... at the end of the DN all goes well, otherwise the subjectAltName extension is empty. The same seems to happen to the Issuer Alternative Name too, but more tests are needed. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: ca Problems - subject and issuer AltName
Massimiliano Pala wrote: The same seems to happen to the Issuer Alternative Name too, but more tests are needed. I have tested it, and it seems like I already said: if the Email field is at the end of the name (Issuer/subject) the altName extension is correctly filled, otherwise it gets an EMPTY value. Let me know if you want me to fix it or if you are taking the task... C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
New ca.c req.c Patches
Hi, I am sending in the patches (for Bodo: I know It was due to the end of the week, but I will re-send them - as many wrote in asking for the patches I am sending it to the lists too). To use the patch, put the madwolf.patch into the openssl-SNAP-20010228 dir and type: $ patch -p0 madwolf.patch If all goes well you should have the new versions of the two files. Now some explanation: req.c = o Fixed some "usage" lacking messages (passin,subject): -subject output the request's subject -passinprivate key password source o Added some new switch: -batch do not ask anything during request generation -subj arg use the passed subject in new request generation -modsubj arg modify request's subject to arg * The -batch will not prompt for any information during new request generation so defaults value will be used. * The -subj will allow for subject name specification during new request generation. The subject name format is: "CN=Some Name, OU=myOU, C=IT" or "CN=Some Name/OU=myOU/C=IT" the two will be correctly parsed. The order will be preseved into request's subject. All known nid are allowed, unknown will be ignored. * The -modsubj will allow to modify a request's subject after its creation - the request will no more be valid when verifying it - I really am not sure about its usability anyway it just required few code lines to be added. ca.c o Added one new switch: -subj arg - Use arg instead of request's subject * The -subj will allow for subject name arg to be used instead of the request's subject name. Useful when issuing certificates with modified subject (by RA operator) without requiring the user to submit again for a certificate because of errors in subject. This is useful for IE/Server requests. The subject's format is the same as the one reported for the -subj request's new switch. Hope this will help in CA managing. C'you, Massimiliano Pala ([EMAIL PROTECTED]) --- apps/ca.c Thu Feb 22 16:00:08 2001 +++ apps/ca-openca.cThu Mar 1 10:59:05 2001 @@ -183,6 +183,7 @@ " -batch - Don't ask questions\n", " -msie_hack - msie modifications to handle all those universal strings\n", " -revoke file- Revoke a certificate (given in file)\n", +" -subj arg - Use arg instead of request's subject\n", " -extensions .. - Extension section (override value in config file)\n", " -extfile file - Configuration file with X509v3 extentions to add\n", " -crlexts .. - CRL extension section (override value in config file)\n", @@ -208,24 +209,25 @@ static int save_serial(char *serialfile, BIGNUM *serial); static int certify(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy,TXT_DB *db, - BIGNUM *serial, char *startdate,char *enddate, int days, - int batch, char *ext_sect, LHASH *conf,int verbose); + BIGNUM *serial, char *subj, char *startdate,char *enddate, + int days, int batch, char *ext_sect, LHASH *conf,int verbose); static int certify_cert(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy, - TXT_DB *db, BIGNUM *serial,char *startdate, + TXT_DB *db, BIGNUM *serial, char *subj, char *startdate, char *enddate, int days, int batch, char *ext_sect, LHASH *conf,int verbose); static int certify_spkac(X509 **xret, char *infile,EVP_PKEY *pkey,X509 *x509, const EVP_MD *dgst,STACK_OF(CONF_VALUE) *policy, -TXT_DB *db, BIGNUM *serial,char *startdate, +TXT_DB *db, BIGNUM *serial,char *subj, char *startdate, char *enddate, int days, char *ext_sect,LHASH *conf, int verbose); static int fix_data(int nid, int *type); static void write_new_certificate(BIO *bp, X509 *x, int output_der, int notext); static int do_body(X509 **xret, EVP_PKEY *pkey, X509 *x509, const EVP_MD *dgst, - STACK_OF(CONF_VALUE) *policy, TXT_DB *db, BIGNUM *serial, + STACK_OF(CONF_VALUE) *policy, TXT_DB *db, BIGNUM *serial,char *subj, char *startdate, char *enddate, int days, int batch, int verbose, X509_REQ *req, char *ext_sect, LHASH *conf); +static X509_NAME *do_subject( char *subject ); static int do_revoke(X509 *x509, TXT_DB *db, int ext, char *extval); static int get_certificate_status(const char *ser_status, TXT_DB *db); static int do_updatedb(TXT_DB *db); @@ -280,6 +282,7 @@ char *serialfile=NULL; char *extensions=NULL; char *extfile=NULL; + char *subj=NULL;
Re: ca Problems - subject and issuer AltName
Dr S N Henson wrote: I've checked in a fix for this. Patch is: [...] Steve. Thanks. I will re-send my patches to Bodo at the end of the week as he said. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Request DN changing
Hi all,
I am trying to modify a request DN and save it into an
alternate file/output.
I have succeded in generating a new DN from a string and
I get no error when using:
if(!X509_REQ_set_subject_name ( req, n ))
return(0);
where the req is the loaded request and n is the X509_NAME
generated structure.
The new subject name is displayed correctly when using the:
if( verbose )
{
print_name(bio_err, "new subject=",
X509_REQ_get_subject_name(req), nmflag);
}
But when sending it out I get the old DN:
i=PEM_write_bio_X509_REQ(out,req);
Why ??? I am patching the req.c file, but I am stuck with this
problem. Someone can help ???
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
Re: Request DN changing
Dr S N Henson wrote: The X509_REQ ASN1 routines cache the signed portion of a request to avoid possible signature errors with invalid encodings. Normally a request will not be modified after it has been signed or received so this doesn't matter. However in your case you are changing it so the cached version is no longer valid. So you should set req-req_info-enc.modified to 1. Thanks. I'll update the code right now. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
ca Problems
Hi all,
I am working on the ca.c command. I want to be able to pass
a new subject to the ca command to issue the new certificate
with the new subject.
I've almost ended, anyway I get strange behaviour.
In the ca command I have added a function to modify the
req subject name so in the do_body it will results like
the following:
BIO_printf(bio_err,"The Subjects Distinguished Name is as follows\n");
if (subj)
X509_REQ_set_subject_name(req,do_subject(subj));
name=X509_REQ_get_subject_name(req);
The subj contains the new subject in text format while the
do_subject returns the X509_NAME related structure. It all
works ok, except for the subjectAltName.
If I use the -preserveDN switch I get no subjectAltName
(empty) while without -preserveDN all goes well.
This either if I use the new subj or not. The preserve code
is ever the same (I did not have the need to change it):
if (preserve)
{
X509_NAME_free(subject);
subject=X509_NAME_dup(X509_REQ_get_subject_name(req));
if (subject == NULL) goto err;
}
I cannot fix this, I tried almost everything: I am surely
missing something. Someone can help me ??
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
CA crl Bug - SNAP 26 Gen 2001
Hi, i probably found a bug in the ca.c program where it sorts the REVOKED certificate: sk_X509_REVOKED_sort(ci-revoked); /* Line 1400 ~ */ the problem is related to the fact that with empty index.txt file the ci-revoked value is 0: this causes a segmentation fault. Fixing it can be done in two ways, one is checking for the ci-revoked value and, in case it is NULL, then we simply don't sort anything; the other is to check the sk_X509_REVOKED_sort (wich I think points to sk_sort) and allow for NULL values to be passed. What is the best solution ? Let me know. I am not sending any patch right now because I am waiting for suggestions about where to fix. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: CA crl Bug - SNAP 26 Gen 2001 - patch
Massimiliano Pala wrote:
Hi,
i probably found a bug in the ca.c program where it sorts the REVOKED
certificate:
sk_X509_REVOKED_sort(ci-revoked); /* Line 1400 ~ */
the problem is related to the fact that with empty index.txt file the
ci-revoked value is 0: this causes a segmentation fault. Fixing it
can be done in two ways, one is checking for the ci-revoked value
and, in case it is NULL, then we simply don't sort anything; the other
is to check the sk_X509_REVOKED_sort (wich I think points to sk_sort)
and allow for NULL values to be passed.
As patching the ca for the first solution is very easy I am sending it
(I needed something fixing it right now so ... ). Let me know.
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
--- ca.cSat Jan 27 14:19:29 2001
+++ ca.new Sat Jan 27 14:16:58 2001
@@ -1397,13 +1397,15 @@
}
/* sort the data so it will be written in serial
* number order */
- sk_X509_REVOKED_sort(ci-revoked);
- for (i=0; isk_X509_REVOKED_num(ci-revoked); i++)
+ if ( ci-revoked )
{
- r=sk_X509_REVOKED_value(ci-revoked,i);
- r-sequence=i;
+ sk_X509_REVOKED_sort(ci-revoked);
+ for (i=0; isk_X509_REVOKED_num(ci-revoked); i++)
+ {
+ r=sk_X509_REVOKED_value(ci-revoked,i);
+ r-sequence=i;
+ }
}
-
/* we now have a CRL */
if (verbose) BIO_printf(bio_err,"signing CRL\n");
if (md != NULL)
S/MIME Cryptographic Signature
subjectAltName extension problem (email:copy bug ?)
Hi,
Probably there is a bug in the subjectAltName setting and the
email:copy option. I have in the config file the line:
subjectAltName=email:copy
And when Issuing a new certificate I get an Empty AltName ext.
I have also tried modifying the extention:
subjectAltName=email:copy,some@someplace
And I get a certificate with only "some@someplace" contents. Obviously
I have used a request with the "EMAIL" field set... Have someone
experienced the same problem or am I wrong in extension usage ???
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
Re: ca -extfile [PATCH] and CVS access
Hi, when trying to compile the latest SNAP, I get on the following computer: K7 Thunderbird 1Gh 128Mb Ram Linux 2.4.0-test12 RedHat 7.0 + Updates the following error: making all in crypto/lhash... make[2]: Entering directory `/usr/local/devel/madwolf/original/openssl-SNAP-20010110/crypto/lhash' gcc -I.. -I../../include -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DNO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c -o lhash.o lhash.c /tmp/ccIaEAwg.s: Assembler messages: /tmp/ccIaEAwg.s:589: Error: immediate operand illegal with absolute jump make[2]: *** [lhash.o] Error 1 make[2]: Leaving directory `/usr/local/devel/madwolf/original/openssl-SNAP-20010110/crypto/lhash' C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: latest SNAP (0110) problems and 'toupper' question
Ulf Mller wrote: Odd, but I think that has to be a compiler error. Ignore my previous mail, it was a gcc error... lucky me... :-D Updating had fixed the problem, it seems. Anyway, can I use the 'toupper' function in the ca tool to get an 'upper' version of a passed parameter ? Are there some platform-related problems with that ??? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: latest SNAP (0110) problems and 'toupper' question
Richard Levitte - VMS Whacker wrote: From: Massimiliano Pala [EMAIL PROTECTED] madwolf Ignore my previous mail, it was a gcc error... lucky madwolf me... :-D Updating had fixed the problem, it seems. It might be a good idea for us to know what gcc version caused the problem. The system was: K7 Athlon Linux 2.4.0-test12 RedHat 7.0 (that's why, I suppose) gcc-2.96 (rpm gcc-2.96-56) I simply updated the gcc rpm wiht the gcc-2.96-69 and this fixed the compilation errors. I also, but I don't think this is the point, updated the libstdc++ to 2.96-69, libstdc++-devel to 2.96-69 and gcc-c++ to 2.96-69. Hope this helps. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
[PATCH] -extfile file for ca tool
Hi all,
I added a new feature in the ca tool wich (just like in the x509 one) adds
the possibility to indicate another configuration file to be used to load
extensions from.
The tag usage is:
$ openssl ca -cert ... -extfile exts.cnf
inside the exts.cnf you can put sections and use different ones using the
-extensions tag as usual.
I attach the ca.diff file, to apply the patch just copy it into the
openssl-0.9.6/apps directory, cd to that dir and type:
$ patch -p0 ca.diff
Let me know if you find some problems and/or bugs when using it. Also
I would suggest to integrate it into the distribution (let me know if you
do so I must not distribute the patch with the OpenCA package).
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
--- ca.cMon Nov 6 01:08:04 2000
+++ ca.patched Mon Nov 6 01:07:27 2000
@@ -166,6 +166,7 @@
" -msie_hack - msie modifications to handle all those universal strings\n",
" -revoke file- Revoke a certificate (given in file)\n",
" -extensions .. - Extension section (override value in config file)\n",
+" -extfile file - Configuration file with X509v3 extentions to add\n",
" -crlexts .. - CRL extension section (override value in config file)\n",
NULL
};
@@ -207,6 +208,7 @@
static int do_revoke(X509 *x509, TXT_DB *db);
static int check_time_format(char *str);
static LHASH *conf=NULL;
+static LHASH *extconf=NULL;
static char *section=NULL;
static int preserve=0;
@@ -242,6 +244,7 @@
char *outdir=NULL;
char *serialfile=NULL;
char *extensions=NULL;
+ char *extfile=NULL;
char *crl_ext=NULL;
BIGNUM *serial=NULL;
char *startdate=NULL;
@@ -338,6 +341,11 @@
if (--argc 1) goto bad;
passargin= *(++argv);
}
+ else if (strcmp(*argv,"-extfile") == 0)
+ {
+ if (--argc 1) goto bad;
+ extfile= *(++argv);
+ }
else if (strcmp(*argv,"-key") == 0)
{
if (--argc 1) goto bad;
@@ -718,6 +726,34 @@
}
/*/
+ /* We neeed to lookup for extra extentions config file */
+ if (extfile)
+{
+long errorline;
+if (!(extconf=CONF_load(NULL,extfile,errorline)))
+{
+if (errorline = 0)
+BIO_printf(bio_err,
+"ERROR: loading the config file '%s'\n",
+extfile);
+else
+BIO_printf(bio_err,
+"ERROR: on line %ld of config file '%s'\n",
+errorline,extfile);
+ ret = 1;
+goto err;
+}
+
+ if( verbose )
+ BIO_printf( bio_err,
+ "Succesfully loaded extensions file %s\n", extfile );
+
+if (!extensions !(extensions = CONF_get_string(extconf,
+ "default", "extensions")))
+ extensions = "default";
+}
+
+ /*/
if (req || gencrl)
{
if (outfile != NULL)
@@ -772,20 +808,27 @@
lookup_fail(section,ENV_SERIAL);
goto err;
}
- if(!extensions)
- extensions=CONF_get_string(conf,section,ENV_EXTENSIONS);
- if(extensions) {
- /* Check syntax of file */
- X509V3_CTX ctx;
- X509V3_set_ctx_test(ctx);
- X509V3_set_conf_lhash(ctx, conf);
- if(!X509V3_EXT_add_conf(conf, ctx, extensions, NULL)) {
- BIO_printf(bio_err,
-"Error Loading extension section %s\n",
+ if(!extconf)
+ {
+ if(!extensions)
+ extensions=CONF_get_string(conf,section,
+ ENV_EXTENSIONS);
+ if(extensions)
+ {
+ /* Check syntax of file */
+ X509V3_CTX ctx;
+ X509V3_set_ctx_test(ctx);
+
Re: Sign/Verify a text using PKCS#7
"Hellan,Kim KHE" wrote:
Hi
I have a private key (PEM), certificate/root certificate (DER) and a small
text: "This is a test".
Using PKCS#7, I would like to make a small test program, where I sign the
text with the private key, write this PKCS#7 object to a file, read the file
again and then verify the signature.
Could anyone please tell me which OpenSSL functions I must use to accomplish
that and in what order they must be called.
Feel free to tell me to RTFM, if it is in there somewhere..I just
couldn't find it :-)
TIA
Kim Hellan
Hi,
I've been working on an old source that, compiled, will give you the ability to
sign and verify the signature. It can sign and include data in the signature.
Simple usage:
usage: sign args
-in file- Input file
-out file - File where to write to
-cert file - Certificate file
-keyfile file - Sign key file
-key- Password protecting the private key
-nd - No detach signature
-verbose- Verbose printing
While Verify tool usage is:
usage: verify args
-in file - Input file
-out file - Output file
-data file- File containing signed data
-cf file - CA's certificate file
-cd certsdir - CAs' certificates directory
-print_data - Print Signed Data to outfile
-no_chain - Verifiy Just signature.
-verbose - Verbose output
You can download it from:
ftp://ftp.openca.org/pub/modules/OpenCA-SV-0.5.98.tar.gz
Hope this will solve your problems... :-D
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
Re: OpenSSL and SCEP
[EMAIL PROTECTED] wrote: Has anyone done any SCEP work with OpenSSL? I need to receive a PKCS#10 certificate request from a client and use SCEP to get a certificate from a CA. I've got some of the work done, but I guess there's no need to reinvent the wheel if there's open source stuff available. Hi, I am from the OpenCA project. I've been contacted some time ago from the SURFnet ExpertiseCentrum (nl) about their work on the SCEP and the possibility to integrate our work. If you do like to contribute let me know (Open Source is a must for us). It seems like many people actually are woering on it and are willing for coordinating their work C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
PERL Module Problem...
Hi all, I have a problem while writing a PERL module. When I want to issue an openssl command (that requires input) the following code (which works in common PERL programs) does not pass the required input to openssl so it waits for user input: open(FD, "|$command" ) || return; ## Send Password print FD "$passwd\n"; ## Send Confirmation Password print FD "$passwd\n"; close(FD); Where command is, for example: /usr/local/ssl/bin/openssl genrsa -des3 -out priv.key 512 The output I get is: Generating RSA private key, 512 bit long modulus ... . e is 65537 (0x10001) Enter PEM pass phrase: but it should not hang asking for passwd as I pass it to openssl with the print command. What's wrong here in ?? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: PERL Module Problem...
Thanks to all who sent me their help. I found it very singular that using inside a cgi script the code works... :-D I will investigate deeply ... (If I have time to ... ) C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Any current OCSP patches ?
Peter Onion wrote: Folks, I just looked back at the OpenSSL status announcements, and the ocsp patches from the openca guys seem to have been removed at some point since November '99(I think). Are there any current OCSP patches or has ocsp been included in the openssl packeage. I had a quick look int the latest snapshot but I cane find anything. Peter Onion. I had an old OCSP patch available. Please consider it is somehow a bit old but it should work. I am planning a new version but it will take some time to be available. You can download the old patches from: ftp://ftp.openca.org/pub/patches/openssl/openssl-SNAP-19990907-ocsp.tar.gz C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: [Fwd: OCSP and CSL]
Dr Stephen Henson wrote: Massimiliano Pala wrote: I am forwarding this message to the openssl-dev list so as to ask for support in generating such CSLs (read on). Some chance in getting help to write the code ??? Actually the CRLs do not support extentions in OpenSSL, isn't it ?? Well it does support extensions but not IDP or deltaCRL. Rhe standard CRL generation utility 'ca' can't handle CRL entry extensions either. 'ca' probably isn't suited to the task and something like an option to the 'crl' program to allow a CRL to be generated from a config file would IMHO be the best way. This probably wont make it into 0.9.5 but maybe the next release... What I was thinking was about the signatures of the CRLs with that kind of extentions... can CRLs be signed by a certificate that is not the CA certificate (for their usage them can not be signed by the ca because it is not connected to the net...) ??? It could be useful to add this kind of CSLs to the Apache server to allow for suspension of certificates before issuing a new CRL is possible... What do you think ??? C'you, Massimiliano Pala ([EMAIL PROTECTED]) P.S.: Another question, probably OT (sorry), someone of you is going to the IETF 47th meeting ??? I've been asked to go there to partecipate to the workshops, although a decision is not taken yet, probably there are no funds :-( What's the story for the OpenSSL people (hope better than mine... ) ??? S/MIME Cryptographic Signature
[Fwd: OCSP and CSL]
I am forwarding this message to the openssl-dev list so as to ask for support in generating such CSLs (read on). Some chance in getting help to write the code ??? Actually the CRLs do not support extentions in OpenSSL, isn't it ?? --- Massimiliano Pala ([EMAIL PROTECTED]) [EMAIL PROTECTED] wrote: Massimiliano Pala [EMAIL PROTECTED]@toutatis.comune.modena.it on 01/24/2000 12:51:03 PM Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: OCSP and CSL Hi all, (first of all I apologize for my english(?), now let's go on ... ) working about an OCSP server to be included in the OpenCA package I found very strange the lack of some kind of CSL (Certificate Suspension List). If there is something similar I'm not aware of, please report it and ignore this mail ... For CSL I mean a sort of CRL (same structures, formats), but carrying a list of only suspended certificates: this is obviously useful for ocsp implementations and considering the fact that in most env you'll not be requested for certificate status changing very often, issuing this kind of lists, I think, could be useful. [Tom Gindin] I believe that a CSL, in this sense, is probably just a CRL whose issuingDistributionPoint extension contains an onlySomeReasons field specifying the certificateHold bit and no other bit. This doesn't require any change to the standards. However, it does bring up another point. Why is certificateHold included in ReasonFlags but not removeFromCRL? If a delta CRL is issued for a CRL partitioned by reason code, it seems to me from the definition of issuingDistributionPoint that removeFromCRL could only be included in a delta CRL with the onlySomeReasons field missing, which goes against the point of having CRL's partitioned on a reason code basis at all. If it is assumed that entries with reason removeFromCRL are permitted in any delta CRL whenever ReasonFlags contains certificateHold, we should probably amend the IDP extension description to make this clear. (snip) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Dennis Glatting wrote: Certificate trust is a very relative concept. The focus here seems to be trust in an identification and issuing system. That is not the same as trust in certificate use. Certificate theft is but one very real problem that undermines the credibility of certificates in general. If people install certificates on their PCs, as we would expect, the incident of break-in and theft (e.g., lap tops) is currently very high. Because most private keys are protected by poorly chosen passwords, and a successful decrypt of a private key can be verified against the public key on the same machine, trust of a certificate use system is very low. (To make matters worse, at least in some parts of the USA, a signature can be legally binding.) Additionally, not one web site I have visited in the last year has asked for my client certificate, so the value of having a client certificate, seems to me, is zero. This is because actually everyone thinks about certificates as an enhanced e-commerce, but that's not. E-commerce works great and does not need CAs ... if we do agree to take the digital certificates to the level of ID, then, if we trust our gov. as a CA, then we can vote, sign a contract and so on via Internet (or digital means) so giving impovementes in real life... Another issue that undermines certificate credibility is few systems, including web servers and browsers, actually check CRLs. If you don't check CRLs then PK anything is almost meaningless. Not only CRLs, it is true that almost no software you find currently supports OCSP... ok, that's true, but that is not the point: writing software to implement support to verification services is not a problem for the internet community. I don't think this to be the real problem. So, I don't see any guarantee or meaning to any on-line ID except in limited environments. If we cut the implementation from the model, we can think about starting to develop this kind of view and getting ready for the implementation to come: technical problems usually get solved in short periods when there is the need of them by the communitiy and many protocols and studies are carried out everyday (smart-cards with crypto chips/OCSP/SCVP/etc...). C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Bill Michaelson wrote:
As far as liability being a show stopper, I agree with Ben that it's not.
"Not for profit" doesn't mean free, it just means "at cost". The cost of
managing the liability can be passed on to customers like everything else.
I've long believed that acceptance of liability by CA's is what would truly
make certificates meaningful in a practical sense. I'd rather have a
certificate with (fidelity?) insurance from Lloyd's or Citigroup than
what Verisign offers, and it's really what irks me about the cost.
What if certificates could be issued by Municipalities CAs ? Just like they
issue ID cards ? I mean, now you need a credit-card to demonstrate you are you
and able to spend... thnik about the possibility to get certificates issued
by govenaments (municipalities for examples) ... they are trusted because, if
standards and policies are matched, you generally trust your governments (at
least if you are not American... :-D It's a joke... ). That would guarantee
your ID online and open services that could be offered to nearly every application
you can think of....
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
Re: Production CA needed
I think the discussion should be continued on another mailing list :-D This is really OT, here (sorry people) ... If you can/want to continue discussing it, please subscribe to [EMAIL PROTECTED] C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Erik Aronesty wrote: After the Verisign acquisition of Thawte, there remain few signing authorities who will perform services for a reasonable fee. Maybe the OpenSSL group should launch a new not-for-profit application verification and certificate signing service? We'd be happy to donate lines and equipment. - Erik Aronesty Prime Data Corp. The problem is the liability... anyway if you want to get a free certificate, go to https://secure.openca.org C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Ben Laurie wrote: [...] The problem is the liability... I don't see that that is an inherent problem - though I can see that "not-for-profit" might well discourage the investors that would have to underwrite the liability, at least at first. Cheers, Ben. I was referring to the fact that in many countries (as in Italy) there are laws about Certificate Service Providers that we do not have time/money to guarantee... But I realize now that this is more related to to legally-binding signatures. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Bill Michaelson wrote: After the Verisign acquisition of Thawte, there remain few signing = authorities who will perform services for a reasonable fee. Maybe the OpenSSL group should launch a new not-for-profit application = verification and certificate signing service? We'd be happy to donate = lines and equipment. I do have contacts with the ICE-CAR root CA peple. We can get a certificate there for free and start from there using the OpenCA software. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: [openca-devel:161] Re: Production CA needed
Víctor R. Ruiz wrote: On Wed, Dec 22, 1999 at 08:17:58PM +0100, Massimiliano Pala wrote: Does anyone agree, wants to collaborate, etc ??? I wonder the amount of work of such a project. But seems interesting anyway. The problem I see is the legal side. Greetings, It seems the basic idea circulating is: we do provide a certification authority without any liability from our side (we do not guarantee that certificates' signature can be recognized in any way legally bionding), just like the Verisign certificates are. Indeed when you request a verisign's certificate you are not request for id proof or anything ... just submit a form, that's all. In this framework the new Open-World-Driven CA is due to operate. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: Verisign acquisition of Thawte
Dennis Glatting wrote: The problem is the liability... anyway if you want to get a free certificate, go to https://secure.openca.org C'you, I don't understand that response. Please explain. Verisign, for example, assumes no liability. In fact, they are teflon coated. You are right: to operate like Verisign do there is no problem. What I am always thinking about CAs is the fact that them are not to be considered only for the e-commerce, in fact e-commerce works perfectly without the need of complex CAs structures... Liability is concerned with digital ID and legally binding signatures: this is what, to me, complex CAs structures are for. Indeed I see certificates to be like ID cards: you can sign contracts, get merried or vote using a digital ID certificate. I admit it is too early for this kind of vision, but think about it for a moment. We are in the same situation where Internet Service Providers were some years ago: now Internet access is almost free... you know why ??? Because the real business is not related to the selling of Internet access, but to the providing of services. The same, I think, could be applied to certificates. The real business is not selling certificates (them only are an instrument enhancing our abilities on identification an signing using digital means) but giving services related to certificates. An example could be secure home banking, signing modules on-line with Public Administrations, signing contracts with people all over the net ... good policies and free software can bring even little communities (Municipalities and/or other non governative organization) to provide certification services for free (and for everyone). This applies only if we consider legally binding signatures. In europe there are many projects on how the legal value of digital signature can be determined and/or denied and some countries developed laws (or directive) about it... GUIDeS is an example... For an interesting paper on PKI myths see http://www.counterpane.com/pki-risks.html I've read it. But I am not sure it got the real problems related to CAs and Policies. I do really think BS to be a real God (!!!) anyway he talks mostly on the current situation avoiding the real decisions that are to be taken in the next few years about PKIs (it is a sort of fast-faq-watch-out and big-brother style guide rather then a good reading for people who currently are working on CAs legal aspects definitions). Obviously this is only my vision of the problems related to CAs and digital certificates and I know many are not shared (not yet at least) I know the problem is far from a solution, anyway. C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
Re: apps\ca Y2K bug
Nelson Alves da Silva Filho wrote:
POSSIBLE bug regarding the ca application (OpenSSL-0.9.4).
I think the function ASN1_UTCTIME_set_string (a_utctm.c) is not Y2K safe and,
consequently, the "startdate" and "enddate" entries of openssl.cnf ca section as well.
Nelson.
I ave tested it without actually having real problems. Which code exactly
you think it is not y2k ???
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
Re: OpenSSL CA as trusted CA in Netscape browser - help
NortonNg wrote:
hi..
i saw your post at openssl mailing list about a way to add any arbitrary
CA certificate into certificate database of Netscape Communicator,
i am interesting about it..can you show me the source code.
jkng.
Soory You got the wrong person, mine was only a reply stating that it is very
dangerous to add certificates to Netscape db WITHOUT explicit user acceptance
and that it should be forwarded to Netscape and signaled as a bug: it does not
give the ability to the user to refuse the certificate... :-D
If you want to add a CA certificate to Netscape db, simply send a certificate in
.der format with the
Content-Type: application/x-x509-ca-cert
Then the user will be asked to accept the CA certificate. I send you some code
from the OpenCA project.
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
#!/usr/bin/perl
## Send Certificates Tool - V2.0
## (c) 1999 by Massimiliano Pala and the OpenCA Group
## Uses the OpenCA::TRIStateCGI module by Massimiliano Pala
## to generate, check and manipulate FORMs Objects
use OpenCA::TRIStateCGI;
## Uses the OpenCA::Configuration module by Massimiliano Pala
## to load the configuration file
use OpenCA::Configuration;
my $query = new OpenCA::Configuration;
## Build a Configuration Object
my $config = new OpenCA::Configuration;
## Define the Configuration Name
my $CONFIG = 'secure.cnf';
## Load the Configuration file (read and parse)
if( $config-loadCfg( $CONFIG ) == undef ) {
print "Content-type: text/html\n\n";
configError( "Unable to load configuration file (request.cnf)!");
}
## Flush the output stream
$|=1;
my $cacert = getRequired( 'CACert' );
putCACert( "$cacert" );
## Subroutines Section (Last Modified on 08 September 1998)
## Changes by Massimiliano Pala ([EMAIL PROTECTED])
sub putCACert {
my @keys = @_;
$cacert = $keys[0];
print "Content-Type: application/x-x509-ca-cert\n\n";
open (FD ,"$cacert") or die "Error: Can't access CA Certificate!";
while (FD) {
print $_;
}
close FD
}
sub getRequired {
## Returns required parameter SINGLE STRING VALUE
## this function simplifies the parameter access
## but returns only the first parameter
my $name = @_[0];
my $tmp;
if( ($tmp = $config-getParam($name)) == undef ) {
## If there is an Error, just send the missing
## parameter error to the browser
configError( "Missing Configuration Keyword : $dir" );
}
## If all gone well we should have the value string in
## $ret and return it to the calling funcion;
$ret = $tmp-{VALUES}-[0];
return $ret;
}
sub configError {
my @keys = @_;
my $err = $keys[0];
print $query-start_html(-title="Administration Error",
-BGCOLOR="#FF");
print "CENTERBRHR WIDTH=80%BR/CENTER";
print "OLOLH1FONT COLOR=redError 690 /FONT/H1";
print "OL BConfiguration Error/B. $err./OL/OL/OL";
print "CENTERHR/CENTER\n/BODY\n/HTML\n";
}
S/MIME Cryptographic Signature
Re: CA DB Support
Dr Stephen Henson wrote: I've often considered using some kind of database for certificates. One problem is getting something that compiles on all platforms. We could get cooperation from the OpenLDAP people as they had to do it and I think they done a very good job. However I could say we can take in charge to add this functionality to OpenSSL/ca program (if you say it will be added to the project) or distribute something in parallel in our own package. I know the ca app was not meant to fully run a ca but as you might think our project is strictly related to the OpenSSL layer and the ca app could be a very useful link (so we do not have to distribute patches to OpenSSL instead we could use it as it was compiled by the user) between our web- based interface and the crypto layer. What do you think about it ??? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
CA DB Support
Hi all, I was discussing with some people from the OpenCA project and we do think that a DB support (like Berkeley DB, NDBM, GDBM) should be added to the ca application to store certificates' information and assure scalability. What do you know about openssl ca's scalability ? How many certificates currently supports ?? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
