from:"Erwann Abalea"

Re: [openssl-dev] id-kp-OCSPSigning extended key usage

2017-09-12 Thread Erwann Abalea via openssl-dev

Bonjour,

SHALL is not equivalent to a SHOULD, but to a MUST. See RFC2119.

Cordialement,
Erwann Abalea

Le 12 sept. 2017 à 02:46, Winter Mute 
<zshr...@gmail.com<mailto:zshr...@gmail.com>> a écrit :

Hello,
The RFC<https://tools.ietf.org/html/rfc6960#section-4.2.2.2> states that:
OCSP signing delegation SHALL be designated by the inclusion of
id-kp-OCSPSigning in an extended key usage certificate extension
included in the OCSP response signer's certificate.
The use of "SHALL" rather than "MUST" indicates that this recommendation can be 
ignored.
How does openssl handle OCSP responses signed by certificates that do not have 
id-kp-OCSPSigning in the extended key usage certificate extension when the 
responses are not signed by the issuing CA directly?
What informs this decision/policy?
Are there any security implications in including or excluding OCSP-sign in the 
extended key usage extension?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

2016-12-27 Thread Erwann Abalea

Bonjour,

> Le 25 déc. 2016 à 19:44, James Bottomley 
> <james.bottom...@hansenpartnership.com> a écrit :
> 
> On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote:
>> On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
>> <james.bottom...@hansenpartnership.com> wrote:
>> 
>>> I think, since it's a key format, the two above are the potential 
>>> ones.  It would be TCG if they want to take it into their standard,
>>> otherwise PKCS is RSA Inc.
>> 
>> I wouldn't expect RSA inc to be involved into this as part of PKCS.
>> They are dead long time ago and have moved to IETF.
> 
> I think I should give TCG first crack at wanting to own the OID.  The
> IETF ones are easy: once you codify it in an RFC, the oid registry auto
> extracts it.

Which OID registry are you talking about?

>>>> However, I'm not sure how expandable is ASN.1 using version
>>>> fields (I've seen no structure being able to be re-used using a
>>>> different version). An alternative approach would to allow for 
>>>> future extensions, i.e., something like the PKIX Extension field, 
>>>> which is an OID+data.
>>> 
>>> As long as the expansion fields are optional, it works nicely. 
>>> X509 and X509v3 are examples of version expanded ASN.1
>> 
>> Only if they are defined in the structure early. Otherwise the early
>> versions of the implementations wouldn't cope with extensions. To 
>> make it early extendable you'd have to use something lilke
>> 
>> TPMKey ::= SEQUENCE {
>>typeOBJECT IDENTIFIER
>>version [0] IMPLICIT INTEGER OPTIONAL
>>emptyAuth   [1] IMPLICIT BOOLEAN OPTIONAL
>>parent  [2] IMPLICIT INTEGER OPTIONAL
>>publicKey   [3] IMPLICIT OCTET STRING OPTIONAL
>>privateKey  OCTET STRING
>> extensions  [4]  EXPLICIT Extensions OPTIONAL
>> }
> 
> Actually, that's the utility of ASN.1, once you use tagging, you don't
> have to do this.  The structure above is identical to:
> 
> TPMKey ::= SEQUENCE {
>typeOBJECT IDENTIFIER
>version [0] IMPLICIT INTEGER OPTIONAL
>emptyAuth   [1] IMPLICIT BOOLEAN OPTIONAL
>parent  [2] IMPLICIT INTEGER OPTIONAL
>publicKey   [3] IMPLICIT OCTET STRING OPTIONAL
>privateKey  OCTET STRING
> }

These structures can be considered identical if and only if one the following 
conditions is true:
 - they’re defined in a module declared with « EXTENSIBILITY IMPLIED »
 - they both include the extensibility marker (i.e. they’re slightly modified)

If you plan to use BER, CER or DER (and only these), then the parser MUST 
ignore the extensibility markers (present or not), and work as if they’re 
present. But that won’t change the ASN.1 definition, only the decoder behaviour.

Cordialement,
Erwann Abalea

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

2016-02-12 Thread Erwann Abalea

Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL 
<u...@ll.mit.edu<mailto:u...@ll.mit.edu>> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff 
like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

2016-02-12 Thread Erwann Abalea via RT

Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL 
<u...@ll.mit.edu<mailto:u...@ll.mit.edu>> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff 
like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

2016-02-11 Thread Erwann Abalea

Bonjour,

Le 11 févr. 2016 à 20:25, Blumenthal, Uri - 0553 - MITLL 
<u...@ll.mit.edu<mailto:u...@ll.mit.edu>> a écrit :

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
<r...@openssl.org<mailto:r...@openssl.org>>
wrote:
On Wed Feb 10 21:59:12 2016, bcri...@gmail.com<mailto:bcri...@gmail.com> wrote:
As the error is suggesting it doesn't like the serialNumber in the
certificate.
If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
get:

13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
DA
: Error: Integer '00 59 ...' has non-DER encoding.
 ^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
contain
leading zeroes.

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others
<http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key
had to say about this:

X.690 edition 2015/08 is freely downloadable from the ITU-T website.
Section 8.3 describes how an INTEGER is to be encoded in BER.
8.3.2 says:

If the contents octets of an integer value encoding consist of more than one 
octet, then the bits of the first octet and bit 8 of the second octet:

a) shall not all be ones; and

b) shall not all be zero.

NOTE – These rules ensure that an integer value is always encoded in the 
smallest possible number of octets.

In this specific example (00 59 …), the bits of the first octets and bit 8 of 
the second octet are all zero. This is invalid.

There is no additional rule for DER on INTEGERs.

Cordialement,
Erwann Abalea

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Support for TLS SHA2-512?

2015-09-25 Thread Erwann Abalea

Bonjour,

> Le 24 sept. 2015 à 21:59, Justin Burke <mlist-openssl-...@alt255.com> a écrit 
> :
> 
> Hello,
> 
> Does OpenSSL support TLS with SHA2-512? I'm able to compile 1.0.1p with
> SHA2-256 and SHA2-384 support, but not with SHA2-512. `openssl ciphers`
> does not list any SHA512 cipher, while `openssl dgst` does support
> SHA512.

The list of registered cipher suites can be found at
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
 
<https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4>
and there’s no standardized *SHA512 cipher suite, as you can see.

Cordialement,
Erwann Abalea

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 0.9.8 support after 31 Dec 2015

2015-07-21 Thread Erwann Abalea

Bonjour,

 Le 21 juil. 2015 à 13:11, Vincent Maury vma...@denyall.com a écrit :
 
 Yes of course.
 But will the dev team suggest backports on this unofficial branch? Can I 
 reasonably expect fixes?

*Suggest* backports, that may or may not be reasonable, depending on growing 
difference between 0.9.8 and head version at the time of vulnerability 
detection.
*Expect* fixes, this seems incompatible with an EOL decision.

 -Message d'origine-
 De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Salz, 
 Rich
 Envoyé : mardi 21 juillet 2015 13:04
 À : openssl-dev@openssl.org
 Objet : Re: [openssl-dev] 0.9.8 support after 31 Dec 2015
 
 could we (0.9.8 users!) expect patch suggestions from the community on 
 potential vulnerabilities found in 2016, in a best effort approach of 
 course, without any official release?
 
 The best thing to do will probably be to fork the branch into a new 
 repository on github and work there.  We will not be checking anything into 
 the official stable branch.
 

Cordialement,
Erwann Abalea

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Using keys from a hardware accelerator

2015-07-20 Thread Erwann Abalea

You’re looking for ENGINE objects.
There’s maybe already an ENGINE directly supporting your hardware module.
If your hardware thing has a PKCS#11 library, a PKCS#11 ENGINE exists.

Cordialement,
Erwann Abalea



 Le 20 juil. 2015 à 17:14, Alexander Gostrer agost...@gmail.com a écrit :
 
 Hi All,
 
 I am working on an OpenSSL modification for a hardware accelerator who 
 generates and uses private keys internally without a way to export/import 
 them. The standard OpenSSL approach is to use keys from files. Is there any 
 preferred way to point to keys in the hardware? There is more and more 
 hardware on the market that people want to use directly from the OpenSSL.
 
 Thank you,
 Alex Gostrer
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails for 3-level cert chain when using X509v3 Authority Key Identifier

2015-06-01 Thread Erwann Abalea

Bonjour,

 Le 30 mai 2015 à 09:48, John Lofgren via RT r...@openssl.org a écrit :
 
 I believe I have pinpointed a typo-error that may be the cause of one or
 two other outstanding bugs related to certificate chain validation. This
 bug only occurs in a chain of certs at least 3 deep when the certs use
 the X509v3 Authority Key Identifier extension.
 
 I am attaching a chain of 3 certs that verifies using the Windows
 Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and
 1.0.1m.
 
 Example failure command:
 openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted
 openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt

This chain is malformed.
In -bug-CS.crt certificate, the AKI.issuername should be C=US, O=OpenSSL, 
CN=openssl verify chain bug Root CA » instead of « C=US, O=OpenSSL, CN=openssl 
verify chain bug Intermediate CA ».

Microsoft doesn’t choke on it because this extension is only a helper and MUST 
NOT be used to (in)validate a certificate chain.

 If have also provided a one line patch to crypto/x509v3/v3_purp.c. I
 believe the error is due to a simple typo. The function X509_check_akid()
 is meant to compare the keyID, serial number, and issuer name between a
 cert and its issuer cert. The keyID and serial number compares are working
 correctly. However, when comparing the issuer name, instead of comparing
 the cert's issuer name to the issuer cert's subject name, it is comparing
 to the issuer cert's *issuer* name.  i.e. instead of comparing to the
 parent name, it is comparing to the grandparent name.

AKI is a helper to identify the issuer certificate. A certificate can uniquely 
be specified by its issuer name and serial number. Therefore, the AKI MUST 
contain the issuer’s issuer name and the issuer’s serial number.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails for 3-level cert chain when using X509v3 Authority Key Identifier

2015-06-01 Thread Erwann Abalea via RT

Bonjour,

 Le 30 mai 2015 à 09:48, John Lofgren via RT r...@openssl.org a écrit :
 
 I believe I have pinpointed a typo-error that may be the cause of one or
 two other outstanding bugs related to certificate chain validation. This
 bug only occurs in a chain of certs at least 3 deep when the certs use
 the X509v3 Authority Key Identifier extension.
 
 I am attaching a chain of 3 certs that verifies using the Windows
 Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and
 1.0.1m.
 
 Example failure command:
 openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted
 openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt

This chain is malformed.
In -bug-CS.crt certificate, the AKI.issuername should be C=US, O=OpenSSL, 
CN=openssl verify chain bug Root CA » instead of « C=US, O=OpenSSL, CN=openssl 
verify chain bug Intermediate CA ».

Microsoft doesn’t choke on it because this extension is only a helper and MUST 
NOT be used to (in)validate a certificate chain.

 If have also provided a one line patch to crypto/x509v3/v3_purp.c. I
 believe the error is due to a simple typo. The function X509_check_akid()
 is meant to compare the keyID, serial number, and issuer name between a
 cert and its issuer cert. The keyID and serial number compares are working
 correctly. However, when comparing the issuer name, instead of comparing
 the cert's issuer name to the issuer cert's subject name, it is comparing
 to the issuer cert's *issuer* name.  i.e. instead of comparing to the
 parent name, it is comparing to the grandparent name.

AKI is a helper to identify the issuer certificate. A certificate can uniquely 
be specified by its issuer name and serial number. Therefore, the AKI MUST 
contain the issuer’s issuer name and the issuer’s serial number.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OID with length zero related bug

2015-04-09 Thread Erwann Abalea


This is a corner case, but an interesting one.

An empty OBJECT IDENTIFIER has no meaning, since it can't identify 
anything. Therefore, one shouldn't be able to allocate such a thing, 
even less encode it.


The CSR is of course invalid, but the previous one was also invalid; OID 
0.0 does not identify a signature algorithm (it's the OID { itu-t 
recommendation }).


The decoding step of the 0600 hex sequence correctly produces a BAD 
OBJECT, since it's an invalid encoding of an OID.
So having an error when decoding such a CSR is a correct behaviour and 
should be expected.


--
Erwann ABALEA

Le 09/04/2015 14:36, Juan Antonio Osorio a écrit :

Hi,

I've recently encountered that OpenSSL is sending some unexpected 
errors when reading X.509 certificate requests, if the key is not 
specified, or the CSR is not signed.


Now, this seems to happen because it now will specify a length=0 in 
the ASN.1 structure since the OID is not set (since the key is not 
specified). And I think this behaviour was introduced in this commit: 
2e430277578d3dd586cd005682a54a59d6158146


So, when using asn1parse to read such a CSR, the section that would 
contain the key has BAD OBJECT, and will throw an error such as 
'invalid object encoding' from 'c2i_ASN1_OBJECT' when the certificate 
is read or loaded. It used to be the case that it would return an OID 
0.0 with length=1, but, like I said, this is not the case anymore.


I'm using OpenSSL 1.0.2a.

I reproduced this error while testing some code using pyOpenSSL. and 
here's how I reproduced it: http://pastebin.com/Ky1e8Gz0


the asn1parse dump of the CSR that causes the error looks like this:
http://pastebin.com/2EvuaLsk

While, in OpenSSL 1.0.1f, (the version where I tested this problem 
doesn't happen), it would look like this:

http://pastebin.com/0vzu2zzx

Now, I'm not sure how to actually report this bug, since I'm not sure 
if it's a bug related to the way the CSRs are being interpreted, or a 
bug related to how the ASN.1 structure is being written. Any insights?


BR
--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com mailto:jaosor...@gmail.com



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl x509 -text incorrectly displays non-latin (non-ansi) symbols (missed '-utf8 option?)

2015-03-02 Thread Erwann Abalea


Bonjour,

Probably an openssl-users question.

Use openssl x509 -text -in localhost-server.crt -nameopt 
oneline,utf8,-esc_msb

Your terminal must be able to display UTF8 sequences.

I sometimes add the show_type nameopt option, to check things.

--
Erwann ABALEA

Le 02/03/2015 06:58, Ikonta a écrit :

AFAIR in 2004 openssl switched to UTF8 as default bitmask in certificate.
But ANSI extension's of utf8 support is still incomplete:

$ openssl x509 -text -in localhost-server.crt
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1 (0x1)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, 
L=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, 
OU=Apache, CN=\xD1\x82\xD0\xB5\xD1\x81\xD1\x82\xD0\xBE\xD0\xB2\xD1\x8B\xD0\xB9 
\xD0\xA6\xD0\x90/emailAddress=root@localhost
 Validity
 Not Before: Feb  6 08:28:23 2015 GMT
 Not After : Sep 15 08:28:23 2020 GMT
 Subject: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, 
O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache web server, 
CN=localhost/emailAddress=apache@localhost
…
(not attaching exanple certificate file because mail list seems to reject such 
letters)
displays utf8 symbol codes instead of expected human-readably letters (in this 
case —  cyrillic), shown after import this certificate into browser's profile.

Probably adding -utf8 option for x509 command should fix this particular issue.

P.S. I use =dev-libs/openssl-1.0.1k amd64 build on Gentoo GNU/Linux.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3726] Cocoapods install BUG

2015-03-02 Thread Erwann Abalea


It seems all the tarballs have disappeared.

--
Erwann ABALEA

Le 02/03/2015 18:06, Alex Sklyar via RT a écrit :

Hello guys. There is a issue with openssl pod installing with cocoapods tool. 
The URL «https://www.openssl.org/source/openssl-1.0.2.tar.gz» is dead.



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Erwann Abalea


Le 17/12/2014 17:34, Salz, Rich a écrit :

#define PEM_STRING_X509_PAIRCERTIFICATE PAIR
   (note, this is supposed to encapsulate a CertificatePair structure
from X.509)

This is not used anywhere in openssl.  I just removed it and did a build :)  
The fact that the fields are named forward and backward, makes me think it was 
intended for SSL/TLS use.  But as I said it's not used and I'll remove it soon.


It's an object type defined in X.509 to support cross-certification. It 
can be used as an LDAP attribute (see RFC4523, section 2.3, 
CertificatePair).


I haven't seen it used, and it doesn't need to have a PEM representation 
(LDAP requires a binary transmission).


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding GET support to ocsp app

2014-09-26 Thread Erwann Abalea


Bonjour Rich,

+static char* urldecode(char* p)
+   {
+   unsigned char* out = (unsigned char *)p;
+   char* save = p;
+
+   for ( ; *p; p++)
+   {
+   if (*p == '+')
+   *out++ = ' ';

You're doing HTML-entity decoding here. URL decoding uses only the 
%xx stuff. See RFC3986.


+   else if (*p != '%')
+   *out++ = *p;


[...]

+   }
+   /* URL decode? Really shouldn't be needed. */
+   if (strchr(p, '+') != NULL  strchr(p, '%') != NULL)
+   p = urldecode(p);

URL decode is necessary (RFC2560 says so, RFC3986 lists '+' and '/' 
among the reserved characters that need to be encoded). In practice, GET 
OCSP requests *are* URL encoded. And if by chance the request isn't 
encoded, your test for the presence of a + and current urldecode() job 
will render this request invalid if is contains a + (it can happen in 
a Base64 encoded string).


--
Erwann ABALEA

Le 26/09/2014 04:56, Salz, Rich a écrit :

I don't see where the OCSP request is de-base64-ified, and URL-decoded.
In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but it's done 
directly on the HTTP request line for a GET.

I forgot to post the updated patch.  Thanks Erwann.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: [openssl.org #3525] CRL tool doesn't show leading 0's in output

2014-09-13 Thread Erwann Abalea



Le 11/09/2014 19:12, Kurt Roeckx via RT a écrit :

On Thu, Sep 11, 2014 at 09:32:26AM -0400, Salz, Rich wrote:

I think the bug is that we need to ouput a leading zero to avoid confusing the 
number as negative.

It's my understanding that for the encoding of the number without
the leading 00 we need to go and add the 00 in front of it because
we would otherwise create a negative number and those aren't allowed
by RFC5280, so we would write that one with the leading 00.  But I
don't see a reason why the encoding can't have multiple leading 00s
in it, and for instance always have a fixed size.


BER/DER states that the encoding of an INTEGER MUST be the smallest 
possible of octets (X.690, section 8.3.2).



So the question is are serial numbers matched based on the number
themself or on the binary form?  I can't find anything currently
that says how to compare them, but I would actually expect that
the binary represenation should be the same.  And if the binary
represenation is important, I think we should print the leading
00s if there are any.


We're manipulating serial numbers, which are INTEGERs, not OCTET STRINGs.
The comparison/match is then a numeric one. Leading 00 isn't important 
for the comparison/match.


openssl crl should print a leading 00 to avoid confusion, but it's 
not really important.


--
Erwann ABALEA

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Adding GET support to ocsp app

2014-09-13 Thread Erwann Abalea



Le 11/09/2014 19:45, Salz, Rich a écrit :


The attached diff adds GET support to ocsp.  I'd appreciate any feedback.



I don't see where the OCSP request is de-base64-ified, and URL-decoded.
In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but 
it's done directly on the HTTP request line for a GET.

Re: [openssl-dev] Adding GET support to ocsp app

2014-09-12 Thread Erwann Abalea


(trying a resend, my email address has changed)

Le 11/09/2014 19:45, Salz, Rich a écrit :


The attached diff adds GET support to ocsp.  I'd appreciate any feedback.



I don't see where the OCSP request is de-base64-ified, and URL-decoded.
In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but 
it's done directly on the HTTP request line for a GET.

Re: [openssl-dev] SHA-3 availability

2014-02-12 Thread Erwann Abalea


Bonjour,

SHA3 is not standardized yet. Keccak has been chosen in the end, but its 
parameters are still debated.
I'm pretty sure that once those parameters are fixed in stone, there 
will be an implementation in OpenSSL.


--
Erwann ABALEA

Le 12/02/2014 11:29, Francis GASCHET a écrit :
The OFTP2 support group is going to start upgrading the cipher suite 
supported in OFTP2.
The proposal includes SHA-3, which is supported by Java 
implementations (BouncyCastle at least).

Is there some plan to support it in openSSL ?

Re: [openssl-dev] MD5 in openSSL internals

2013-04-23 Thread Erwann Abalea

MD5 is used in TLS1.0 for RSA signing and random derivation (PRF). See 
RFC2246.

(Please note that OpenSSL hasn't been mentioned in this sentence).

SHA256 used for the PRF is available with TLS1.2 only. SHA256 used for 
the HMAC is available for some ciphersuites defined for TLS1.2 only (but 
I think you could define your own with TLS1.0).


--
Erwann ABALEA

Le 23/04/2013 08:29, Venkataragavan Narayanaswamy a écrit :


Hi,

We are currently analyzing and understanding the security strength of 
the openSSL internal implementation to certify the products.


In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer 
the following or provide me with the documentation reference


1.Does openSSL library use MD5 internally for any operation?

2.Can we have SHA256 in the ciphersuite with TLSv1.0?

Thanks,

Venkat

Re: [openssl-users] Re: [openssl-dev] MD5 in openSSL internals

2013-04-23 Thread Erwann Abalea


You're right.

PRF in TLS1.0 is done by splitting the secret in 2 parts, hashing the 
first with MD5, hashing the second with SHA1, and XORing the 2 results.
RSA signing in TLS1.0 is done by hashing the data with MD5 and SHA1, 
concatenating the 2 hash results, and signing the 36 bytes result (with 
PKCS#1v1.5 padding).


PRF construct depends on pre-image resistance. MD5 and SHA1 are still 
considered pre-image resistant.
RSA signing depends on collision resistance. MD5 is not collision 
resistant, SHA1 is not considered academically collision resistant, but 
there's no known attack on collision of both MD5 and SHA1 at the same time.


--
Erwann ABALEA

Le 23/04/2013 14:28, David Jacobson a écrit :

Careful about this.  The technically correct answer is misleading.

Yes, MD5 is used in the PRF, but it is XORed with SHA1.  So you get at 
least the strength of stronger of the two.


--David Jacobson

On 4/23/13 3:31 AM, Erwann Abalea wrote:
MD5 is used in TLS1.0 for RSA signing and random derivation (PRF). 
See RFC2246.

(Please note that OpenSSL hasn't been mentioned in this sentence).

SHA256 used for the PRF is available with TLS1.2 only. SHA256 used 
for the HMAC is available for some ciphersuites defined for TLS1.2 
only (but I think you could define your own with TLS1.0).


--
Erwann ABALEA

Le 23/04/2013 08:29, Venkataragavan Narayanaswamy a écrit :


Hi,

We are currently analyzing and understanding the security strength 
of the openSSL internal implementation to certify the products.


In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer 
the following or provide me with the documentation reference


1.Does openSSL library use MD5 internally for any operation?

2.Can we have SHA256 in the ciphersuite with TLSv1.0?

Thanks,

Venkat

Re: [openssl-dev] [openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types

2013-03-28 Thread Erwann Abalea


The countryName field is a PrintableString, that's mandatory (see X.520).
It also MUST be 2 characters long, but that's not enforced by OpenSSL.

--
Erwann ABALEA

Le 28/03/2013 14:33, Joseba Gil Irisarri via RT a écrit :

Hello,

I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is 
configured as follows:

# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix   : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK: a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only

All the strings that my certificate contains are UTF8String, but when trying to 
sign it with OpenSSL CA, it returns the following mismatch error:

The countryName field needed to be the same in the CA certificate DE and the 
request DE

When parsing the OpenSSL CA certificate, I found out the countryName field is 
coded as PrintableString, while in my certificate is coded as UTF8String, hence 
the error. The rest of the string fields are coded as UTF8String in both the CA 
certificate and the request.

My question here is, if OpenSSL string_mask is configured as utf8only, why is 
the countryName field coded as PrintableString? Shouldn´t all fields be coded 
as UTF8String? Perhaps I misunderstood the meaning and use of the string_mask, 
so I would greatly appreciate if you could explain to me whether this is a bug 
or just correct behaviour.

Thanks a lot in advance for your help.

Best regards,
Joseba Gil

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types

2013-03-28 Thread Erwann Abalea via RT

The countryName field is a PrintableString, that's mandatory (see X.520).
It also MUST be 2 characters long, but that's not enforced by OpenSSL.

-- 
Erwann ABALEA

Le 28/03/2013 14:33, Joseba Gil Irisarri via RT a écrit :
 Hello,

 I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is 
 configured as follows:

 # This sets a mask for permitted string types. There are several options.
 # default: PrintableString, T61String, BMPString.
 # pkix : PrintableString, BMPString (PKIX recommendation before 2004)
 # utf8only: only UTF8Strings (PKIX recommendation after 2004).
 # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
 # MASK: a literal mask value.
 # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
 string_mask = utf8only

 All the strings that my certificate contains are UTF8String, but when trying 
 to sign it with OpenSSL CA, it returns the following mismatch error:

 The countryName field needed to be the same in the CA certificate DE and 
 the request DE

 When parsing the OpenSSL CA certificate, I found out the countryName field is 
 coded as PrintableString, while in my certificate is coded as UTF8String, 
 hence the error. The rest of the string fields are coded as UTF8String in 
 both the CA certificate and the request.

 My question here is, if OpenSSL string_mask is configured as utf8only, why is 
 the countryName field coded as PrintableString? Shouldn´t all fields be coded 
 as UTF8String? Perhaps I misunderstood the meaning and use of the 
 string_mask, so I would greatly appreciate if you could explain to me whether 
 this is a bug or just correct behaviour.

 Thanks a lot in advance for your help.

 Best regards,
 Joseba Gil
   
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Security of RC4 in TLS

2013-03-15 Thread Erwann Abalea


Le 15/03/2013 11:34, Huzaifa Sidhpurwala a écrit :

On Fri, Mar 15, 2013 at 3:39 PM, Erwann Abalea
erwann.aba...@keynectis.com wrote:

Bonjour,
In my understanding, after a fast read of RFC5246, this won't work.

If RC4 is finally considered weak (at last), just don't use it anymore. Do
you use DES on your server? I guess no.

Thanks for a quick reply.

Perhaps i was not clear. I am not worried about _my_ server.

I just noticed some work being done in other SSL/TLS
open source library about this issue, and hence the question.

There is also some discussion at:
https://news.ycombinator.com/item?id=5364807


What I'm reading there is only a proposition to apply the 1/n-1 trick on 
RC4 ciphersuites also (an AGL proposition).
Because TLS is MAC-then-encrypt, that will consume 1+MAC_length bytes of 
the RC4 keystream. Either 21 or 17 bytes, depending on the MAC used 
(SHA1 or MD5). The other 235/239 bytes will still be predictable. Repeat 
the process until you have consumed the first 256 bytes of the RC4 
keystream. For small sized requests (as are most requests), this has a 
non negligible cost (20 bytes of MAC for 1 byte of payload, +TLS 
encapsulation, repeated 13 times).



I guess the OpenSSL solution is to not use RC4 then?


OpenSSL has to be compatible with TLS specs, *and* other TLS stacks.
The 0/n or 1/n-1 tricks are valid according to TLS specs, but broke 
compatibility with other stacks.
Modifying how RC4 is used isn't compatible with TLS specs, so it'll 
break compatibility even more.


An openssl-based application could remove RC4 as the list of advertised 
ciphersuites (that's easy on Apache, for example). But that's more a 
server solution.
Since this attack is targetted toward clients, a client detecting that 
RC4 is in use could add something before sensible data so that this 
sensible data is beyond the 256 bytes predictibility horizon. Of course, 
this something has to be compatible with the underlying protocol and 
shouldn't change the semantics of the message. With HTTP, adding 
proprietary junk header is possible.


This isn't an OpenSSL question, in fact. RC4 has known flaws, its use in 
TLS has been enforced recently because it was an easy solution to the 
BEAST attack.
A better solution (to BEAST) is to move on to TLS1.1+. A good solution 
to CRIME is to disable compression. A good solution to LUCKY13 is to 
avoid CBC.
Drop RC4 when possible, add AES-GCM with TLS1.1+ wherever you can, 
upgrade software ASAP.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support

2013-03-01 Thread Erwann Abalea

IMHO, it's more OpenSSL users' job (programs and libraries), not 
directly OpenSSL.


--
Erwann ABALEA

Le 01/03/2013 16:08, russell.aspinw...@bcs.org.uk via RT a écrit :

Hi,

Would you consider adding support for RFC6698 Domain Authentication of
Named Entities (DANE) Transport Layer Association within OpenSSL to
facilitate the wide spread adoption of this technology.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support

2013-03-01 Thread Erwann Abalea via RT

IMHO, it's more OpenSSL users' job (programs and libraries), not 
directly OpenSSL.

-- 
Erwann ABALEA

Le 01/03/2013 16:08, russell.aspinw...@bcs.org.uk via RT a écrit :
 Hi,

 Would you consider adding support for RFC6698 Domain Authentication of
 Named Entities (DANE) Transport Layer Association within OpenSSL to
 facilitate the wide spread adoption of this technology.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2879] Bug report - X509_check_akid() incorrectly handles dirName:

2012-09-13 Thread Erwann Abalea


Bonjour,

The goal of this function is to determine if a given 
authorityKeyIdentifier extension matches an issuer certificate 
(issuer=authority).


The AKI extension can contain 3 elements:
 - keyIdentifier
 - authorityCertIssuer
 - authorityCertSerialNumber

(X.509 mandates that the last 2 MUST be present together, this 
constraint is not mentioned in RFC5280)


The first element is to be compared with the issuer's 
subjectKeyIdentifier, is present.


The 2nd and 3rd element are to be compared with the issuer's issuerName 
and issuer' serialNumber, respectively.
They are here to uniquely identify a certificate, and a certificate is 
uniquely identified by its issuer's name and its own serial number.


Therefore the fix is incorrect. If you've got a certificate chain that 
doesn't validate the AKI with the last 2 elements, it surely means your 
certificates are improperly constructed.


--
Erwann ABALEA
-
yachtitropicomythivorotrièdre: triangle des Bermudes

Le 13/09/2012 09:15, David Shambroom via RT a écrit :

Using:
Windows 7 Professional SP1
openssl-1.0.0g

Build:
perl Configure debug-VC-WIN64A no-asm --prefix=c:\openssl
ms\do_win64a
nmake -f ms\nt.mak

source file:
openssl-1.0.0g\crypto\x509v3\v3_purp.c

function:
int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid)

line 762:
  if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
  ^^
I believe this should be:
  if(nm  X509_NAME_cmp(nm, X509_get_subject_name(issuer)))
  ^^^
I have tested and verified this fix.

Best regards,
--David Shambroom


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2879] Bug report - X509_check_akid() incorrectly handles dirName:

2012-09-13 Thread Erwann Abalea via RT

Bonjour,

The goal of this function is to determine if a given 
authorityKeyIdentifier extension matches an issuer certificate 
(issuer=authority).

The AKI extension can contain 3 elements:
  - keyIdentifier
  - authorityCertIssuer
  - authorityCertSerialNumber

(X.509 mandates that the last 2 MUST be present together, this 
constraint is not mentioned in RFC5280)

The first element is to be compared with the issuer's 
subjectKeyIdentifier, is present.

The 2nd and 3rd element are to be compared with the issuer's issuerName 
and issuer' serialNumber, respectively.
They are here to uniquely identify a certificate, and a certificate is 
uniquely identified by its issuer's name and its own serial number.

Therefore the fix is incorrect. If you've got a certificate chain that 
doesn't validate the AKI with the last 2 elements, it surely means your 
certificates are improperly constructed.

-- 
Erwann ABALEA
-
yachtitropicomythivorotrièdre: triangle des Bermudes

Le 13/09/2012 09:15, David Shambroom via RT a écrit :
 Using:
 Windows 7 Professional SP1
 openssl-1.0.0g

 Build:
 perl Configure debug-VC-WIN64A no-asm --prefix=c:\openssl
 ms\do_win64a
 nmake -f ms\nt.mak

 source file:
 openssl-1.0.0g\crypto\x509v3\v3_purp.c

 function:
 int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid)

 line 762:
   if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
   ^^
 I believe this should be:
   if(nm  X509_NAME_cmp(nm, X509_get_subject_name(issuer)))
   ^^^
 I have tested and verified this fix.

 Best regards,
 --David Shambroom


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [RFC] OpenSSL accepts invalid server cert chain

2012-07-12 Thread Erwann Abalea


Le 12/07/2012 15:36, David Woodhouse a écrit :

I have encountered a server which presents an invalid set of
certificates in its TLS handshake.


This is common. Really common.


It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2-#3-#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to have the
same *name* as the issuer of #1; cf. RT#1942).


If it has the same name, then it's the same CA. Has it been rekeyed?


This violates RFC5246 §7.4.2, which says of the certificate_list that:
   This is a sequence (chain) of certificates.  The sender's
   certificate MUST come first in the list.  Each following
   certificate MUST directly certify the one preceding it.

However, the missing intermediate CA *is* found in my local trust
database, and OpenSSL verifies the server quite happily using *that*.


As do other toolkits and browsers.


This seems wrong — surely the handshake should be rejected? Should I
submit a patch?

I note that GnuTLS *does* reject the server's handshake — and rightly
so, as far as I can tell from the RFC.


Does GnuTLS have access to the missing intermediate CA, too?
GnuTLS is not really a good example, it doesn't follow X.520 naming, and 
doesn't enforce the pathLen constraints.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: SHA-256 and SHA-512 doubts in OpenSSL

2012-06-26 Thread Erwann Abalea


Same here.
Also with 
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf


http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf and 
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf are OK.


--
Erwann ABALEA
-
nocticonsiliophorisme: exploitation des ressources méditatives du sommeil

Le 26/06/2012 17:49, Andy Polyakov a écrit :

I was just able to open the link below and the entire document looked okay.

I observe spaces in places where ~ should be in Ch(), not only in
SHA256, but in all of them. And Figure 1 on page 3 is mostly empty...

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] RE: SHA-256 and SHA-512 doubts in OpenSSL

2012-06-26 Thread Erwann Abalea



Le 26/06/2012 18:24, Bhat, Jayalakshmi Manjunath a écrit :

One more question  CHANGES document in OpenSSL 1.0.1 stats SHA-224 supported as 
per FIPS 180-2, but SHA-224 appears to be available only in FIPS 180-3. So 
shouldn’t it be as per FIPS 180-3 standard?


http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

--
Erwann ABALEA
-
atripodanatoclaste: qui ne casse pas trois pattes à un canard

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2834] bug report: i2d(sign(10)) results in 2573 encoded

2012-06-14 Thread Erwann Abalea

It appears that PKCS7_sign() calls SMIME_crlf_copy() without condition. 
This changes 0x0a into 0x0d, 0x0a (\n into \r\n), respecting S/MIME 
rules.


Since PKCS#7 has nothing to do with S/MIME (the reverse is not true), 
could this SMIME_crlf_copy() be called only when an S/MIME semantic is 
needed?


--
Erwann ABALEA
-
transrhinoscopie: capacité de voir plus loin que son nez


Le 14/06/2012 16:56, Yusheng Yang via RT a écrit :

[...]

This test attempts to sign, encode, decode, and verify messages using 
the PKCS7 API. The messages are single integers. Every integer works 
as expected, except for 10. When I sign 10 and verify the signature, 
the output of the verify is 2573. This is because the result of the 
encoding is 2573 encoded. If you run the test, you'll see that the 
asn1 for 10 shows this:


54:d=5  hl=2 l=   5 prim: OCTET STRING  [HEX DUMP]:0D0A00

0D0A in little endian is 2573. Note that l = 5 instead of 4. If it 
were 4, then the HEX DUMP would be 0A00, which would be correct. 
It appears that there's an extra byte of 0D that's part of the encoded 
string.

Re: [openssl-dev] [openssl.org #2834] bug report: i2d(sign(10)) results in 2573 encoded

2012-06-14 Thread Erwann Abalea via RT

It appears that PKCS7_sign() calls SMIME_crlf_copy() without condition. 
This changes 0x0a into 0x0d, 0x0a (\n into \r\n), respecting S/MIME 
rules.

Since PKCS#7 has nothing to do with S/MIME (the reverse is not true), 
could this SMIME_crlf_copy() be called only when an S/MIME semantic is 
needed?

-- 
Erwann ABALEA
-
transrhinoscopie: capacité de voir plus loin que son nez


Le 14/06/2012 16:56, Yusheng Yang via RT a écrit :
 [...]

 This test attempts to sign, encode, decode, and verify messages using 
 the PKCS7 API. The messages are single integers. Every integer works 
 as expected, except for 10. When I sign 10 and verify the signature, 
 the output of the verify is 2573. This is because the result of the 
 encoding is 2573 encoded. If you run the test, you'll see that the 
 asn1 for 10 shows this:

 54:d=5  hl=2 l=   5 prim: OCTET STRING  [HEX DUMP]:0D0A00

 0D0A in little endian is 2573. Note that l = 5 instead of 4. If it 
 were 4, then the HEX DUMP would be 0A00, which would be correct. 
 It appears that there's an extra byte of 0D that's part of the encoded 
 string.



  
  
It appears that PKCS7_sign() calls SMIME_crlf_copy() without
condition. This changes 0x0a into 0x0d, 0x0a ("\n" into "\r\n"),
respecting S/MIME rules.

Since PKCS#7 has nothing to do with S/MIME (the reverse is not
true), could this SMIME_crlf_copy() be called only when an S/MIME
semantic is needed?

    -- 
Erwann ABALEA
-
transrhinoscopie: capacit de voir plus loin que son nez


Le 14/06/2012 16:56, Yusheng Yang via RT a crit:
[...]
  
This test attempts to sign, encode, decode,
  and verify messages using the PKCS7 API. The messages are
  single integers. Every integer works as expected, except for
  10. When I sign 10 and verify the signature, the output of the
  verify is 2573. This is because the result of the encoding is
  2573 encoded. If you run the test, youll see that the asn1
  for 10 shows this:

54:d=5 hl=2 l= 5 prim: OCTET STRING
  [HEX DUMP]:0D0A00

0D0A in little endian is 2573. Note that l
  = 5 instead of 4. If it were 4, then the HEX DUMP would be
  0A00, which would be correct. It appears that theres an
  extra byte of 0D thats part of the encoded string.

Re: [FEATURE] OCSP functionality patch

2012-06-08 Thread Erwann Abalea


Bonjour,

If the OCSP URL isn't found in the supplied certificate, you're trying 
to find it in its issuer? That's not standard, even if it can work.


It seems you're looking for the issuer by its subject name. When you 
have several CA certificates with the same name in your store (that's 
permitted), you may not get the real issuer certificate, and the 
calculated issuerKeyHash will be wrong.


Please don't add a nonce, at least not by default. Looking at our busy 
OCSP responders, *nobody* asks for a nonce, and it's perfect like this. 
Having a nonce may provide you a benefit, but it defeats CA 
optimizations (cached responses, mainly).


It seems the supplied code doesn't check for a dedicated OCSP 
responder's certificate validity (not necessary if this certificate has 
an OCSPNoCheck extension, but some don't have this extension).


Le 08/06/2012 13:07, Alexander Komyagin a écrit :

[...]
How it works:

1) OCSP revocation check is done right before CRL check
2) first, OpenSSL tries to get the OCSP url for the certificate being
checked - it's either forced url or embedded into the certificate.
3) if it fails, issuer shall be found
4) if OCSP validation for issuer is disabled, we completely trust him
and the check is successful.
5) otherwise, we extract issuer OCSP url the same way as in (2) and use
it to check.

=
Possible errors:
  - X509_V_ERR_CERT_UNKNOWN [OCSP responder never heard about this
certificate]
  - X509_V_ERR_CERT_REVOKED [Certificate had been revoked]
  - X509_V_ERR_APPLICATION_VERIFICATION [for everything else]




P.S  OCSP querying code was taken from OpenSSL ocsp app. Also I still
want to add additional error codes for reporting OCSP-related failures
during verification (obviously, APPLICATION_VERIFICATION_FAILURE doesn't
tell you much).




--
Erwann ABALEA
-
Un forum peut répondre à plusieurs besoins à la fois
Ici, le groupe des débutants dépasse en nombre le groupe des utilisateur
middle-class ce qui provoque inévitablement des tensions.
-+- EF - Guide du Neuneu d'Usenet - La lutte des middle classes -+-

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer

2012-04-03 Thread Erwann Abalea


Le 03/04/2012 09:38, Tamir Khason via RT a écrit :

Please see decrypted private key
http://pastebin.com/DzYLnHZT



Thanks.
You didn't provide information on where you think the error is, 
precisely. I'll base my answer on your previous posts.


You started to say that the coefficients should be of the same length. 
By coefficient, you mean the CRT parameters (exponent1, exponent2, 
coefficient). You didn't provide an authority source to back up this 
assertion. In fact, it's false, and has been explained why. There's no 
optimization trick, no particular decision, some parameters can be 
smaller than others, that happens, and it's not wrong.


You then talked about end-of-content octets. There's no such octet in 
the provided example. And there's no end-of-content octet possible in 
the DER representation of an object. End-of-content octets are found 
with indefinite length objects, when you don't know in advance the size 
of the object you're encoding, but can tell when it ends; think of it as 
streaming, for example. This is allowed with BER only, not DER.


It was explained to you how an integer is serialized in DER, in order to 
be sure that it's the smallest representation of the integer, without 
any confusion between negative and positive numbers. In your provided 
example, all the CRT parameters have their DER serialization starting 
with a leading 00 octet, because the next non 00 octet has its highest 
bit equal to 1, and if this leading 00 octet wouldn't be here the 
serialized number would have been considered a negative number, which is 
not wanted. The fact that exponent1 and coefficient are of the same size 
as prime1 and prime2 is a coincidence (see first paragraph of this 
answer). And the fact that exponent2 has a smaller size is also a 
coincidence.


Is there anything still not clear? Do you still think OpenSSL has a bug? 
If yes, maybe you could consider switching to the openssl-users mailing 
list, which should obviously has been done long ago. Just subscribe to 
this list, and reply on this other list. It is clear to anybody here 
that what you spotted is not a bug in OpenSSL but an incomprehension on 
your side.


Cordialement.

--
Erwann ABALEA
-
Ce ne sont que des propositions. Je ne veux pas les faire passer en
force. Je pense que si mes idées doivent être reprises, elles ne
doivent pas passer au vote, pour plusieurs raison :
-+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+-

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: [openssl.org #2782] BUG report: RSA private key serializer

2012-04-03 Thread Erwann Abalea via RT

Le 03/04/2012 09:38, Tamir Khason via RT a écrit :
 Please see decrypted private key
 http://pastebin.com/DzYLnHZT


Thanks.
You didn't provide information on where you think the error is, 
precisely. I'll base my answer on your previous posts.

You started to say that the coefficients should be of the same length. 
By coefficient, you mean the CRT parameters (exponent1, exponent2, 
coefficient). You didn't provide an authority source to back up this 
assertion. In fact, it's false, and has been explained why. There's no 
optimization trick, no particular decision, some parameters can be 
smaller than others, that happens, and it's not wrong.

You then talked about end-of-content octets. There's no such octet in 
the provided example. And there's no end-of-content octet possible in 
the DER representation of an object. End-of-content octets are found 
with indefinite length objects, when you don't know in advance the size 
of the object you're encoding, but can tell when it ends; think of it as 
streaming, for example. This is allowed with BER only, not DER.

It was explained to you how an integer is serialized in DER, in order to 
be sure that it's the smallest representation of the integer, without 
any confusion between negative and positive numbers. In your provided 
example, all the CRT parameters have their DER serialization starting 
with a leading 00 octet, because the next non 00 octet has its highest 
bit equal to 1, and if this leading 00 octet wouldn't be here the 
serialized number would have been considered a negative number, which is 
not wanted. The fact that exponent1 and coefficient are of the same size 
as prime1 and prime2 is a coincidence (see first paragraph of this 
answer). And the fact that exponent2 has a smaller size is also a 
coincidence.

Is there anything still not clear? Do you still think OpenSSL has a bug? 
If yes, maybe you could consider switching to the openssl-users mailing 
list, which should obviously has been done long ago. Just subscribe to 
this list, and reply on this other list. It is clear to anybody here 
that what you spotted is not a bug in OpenSSL but an incomprehension on 
your side.

Cordialement.

-- 
Erwann ABALEA
-
Ce ne sont que des propositions. Je ne veux pas les faire passer en
force. Je pense que si mes idées doivent être reprises, elles ne
doivent pas passer au vote, pour plusieurs raison :
-+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+-


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea

Bonjour,

Le 02/04/2012 13:21, Tamir Khason via RT a écrit :

There is a bug in ASN.1 DER serializer used to generate RSA private
keys. It trims trailing zeros despite the DER specification. Please
see the full info and reproduction steps in my blog
http://khason.net/dev/openssl-bug-or-why-some-private-keys-cannot-be-used-for-net/#comments

You're wrong. You're mixing things, length encoding and value encoding
(as in TLV).

In DER, there's no indefinite length objects, because the purpose of
DER is to have the only one non ambiguous representation of an object.
Since an indefinite length (i.e. not known in advance) object can also
be represented by its definite length counterpart by rewriting it once
the object length is known, then an indefinite length can't be the
only one representation of this object.

Next, when writing a DER object, its serialization needs to be unique. A
set of rules are applied to enforce this. For integers, these rules tell
us that the lowest number of bytes need to be used, also ensuring that
negative numbers are expressed in 2s complement form (highest bit set to
1). Therefore, while you can express the number 0x32 as the following
serialization forms all representing the same number:

32
0032
32
only the first representation is a DER one. The others encode the same
value, but with useless leading bytes.

Negative numbers cannot have a heading 00 octet, because the highest
order bit would then be equal to 0, and the number considered positive.

Therefore, the number 0x92 can be serialized as:
92
0092
92
only the second form is a DER one. The first has its highest order bit
set to 1, the number considered negative, its value is then -0x6E. The
third form has an unnecessary leading 00 octet.

Of course, adding trailing 00 octets are forbidden, this would
completely change the encoded number. Like writing 70 is not the same
as writing 7.

In your bad example key, exponent2's length is smaller than
exponent1's and coefficient's ones. They're not guaranteed to be of the
same length. Exponent{1,2} and coefficient are results of calculations
(d mod (p-1), d mod (q-1), q^-1 mod p respectively), and their
magnitude can vary.
Any a mod b number cannot be the same size of b (consider for
example 2^32+1 mod 2^32, it's not a 32 bits integer).

If your bad key cannot be used in .NET, there's another reason.

--
Erwann ABALEA
-
podoclaste: casse-pieds

__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea via RT

Bonjour,

Le 02/04/2012 13:21, Tamir Khason via RT a écrit :
There is a bug in ASN.1 DER serializer used to generate RSA private
keys. It trims trailing zeros despite the DER specification. Please
see the full info and reproduction steps in my blog
http://khason.net/dev/openssl-bug-or-why-some-private-keys-cannot-be-used-for-net/#comments

You're wrong. You're mixing things, length encoding and value encoding
(as in TLV).

Negative numbers cannot have a heading 00 octet, because the highest
order bit would then be equal to 0, and the number considered positive.

Of course, adding trailing 00 octets are forbidden, this would
completely change the encoded number. Like writing 70 is not the same
as writing 7.

If your bad key cannot be used in .NET, there's another reason.

--
Erwann ABALEA
-
podoclaste: casse-pieds

__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea

Bonjour,

There's no optimization here.

Consider the following 256bits RSA key components, following the RSA
definition.

p=FD647F21207C128078ED4D815C13BA43
q=D332E9F0E5D1661C4D16DB92A1B2D00B
e=10001

You then have n, the modulus, equal to p*q, which is
D10C39F80BA51AF15BF8F25B1FE9006A50FEA8845644481BCC5F6870A1C570E1.
d, the private exponent, is equal to e^-1 mod (p-1)(q-1), so
5D8966F6C1DF226B148813890A822B18973B9B7BFEA3A4BC658FB68E312300F1 in
this case.

p and q are 128 bits integers, as asked.

exponent1, exponent2 and coefficient are CRT parameters, and are only
useful to speed up private RSA operations. They're not mandatory, so
their size is not defined. Consider them as bonus elements, outside the
scope of RSA definition.

You can do the maths by yourself, exponent1=d mod (p-1), exponent2=d
mod (q-1).

exponent1=20FEF3270729E0E6E5D850DD6576142D
exponent2=2FD959273AEA3638333EFA803E2245

There's nothing strange, or invalid, or optimized here.

Le 02/04/2012 15:28, Tamir Khason via RT a écrit :

Hello, Erwann
This is not related to .NET. Integer is not only value, but also size.
Both exponents and its coefficients should be the same length
(according RSA definition, both integers) so those numbers should be
serialized into ASN1_INTEGER. In for some reason, you want to have
integer with different size (for me it's wrong, but it might be your
decision because of size optimization), you should use variouse size
serialization.

This is what is this bug about.

On Mon, Apr 2, 2012 at 3:52 PM, Erwann Abalea via RTr...@openssl.org wrote:

Bonjour,

Le 02/04/2012 13:21, Tamir Khason via RT a écrit :

You're wrong. You're mixing things, length encoding and value encoding
(as in TLV).

Negative numbers cannot have a heading 00 octet, because the highest
order bit would then be equal to 0, and the number considered positive.

Of course, adding trailing 00 octets are forbidden, this would
completely change the encoded number. Like writing 70 is not the same
as writing 7.

If your bad key cannot be used in .NET, there's another reason.

--
Erwann ABALEA
-
podoclaste: casse-pieds

--
Erwann ABALEA
-
The most beautiful thing we can experience is the mysterious. It
is the source of all true art and all science. He to whom this
emotion is a stranger, who can no longer pause to wonder and
stand rapt in awe, is as good as dead: his eyes are closed.
- Albert Einstein

__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea via RT

Bonjour,

There's no optimization here.

Consider the following 256bits RSA key components, following the RSA
definition.
p=FD647F21207C128078ED4D815C13BA43
q=D332E9F0E5D1661C4D16DB92A1B2D00B
e=10001

You can do the maths by yourself, exponent1=d mod (p-1), exponent2=d
mod (q-1).
exponent1=20FEF3270729E0E6E5D850DD6576142D
exponent2=2FD959273AEA3638333EFA803E2245

There's nothing strange, or invalid, or optimized here.

Le 02/04/2012 15:28, Tamir Khason via RT a écrit :
Hello, Erwann
This is not related to .NET. Integer is not only value, but also size.
Both exponents and its coefficients should be the same length
(according RSA definition, both integers) so those numbers should be
serialized into ASN1_INTEGER. In for some reason, you want to have
integer with different size (for me it's wrong, but it might be your
decision because of size optimization), you should use variouse size
serialization.

This is what is this bug about.

On Mon, Apr 2, 2012 at 3:52 PM, Erwann Abalea via RTr...@openssl.org wrote:
Bonjour,

You're wrong. You're mixing things, length encoding and value encoding
(as in TLV).

Negative numbers cannot have a heading 00 octet, because the highest
order bit would then be equal to 0, and the number considered positive.

Of course, adding trailing 00 octets are forbidden, this would
completely change the encoded number. Like writing 70 is not the same
as writing 7.

If your bad key cannot be used in .NET, there's another reason.

--
Erwann ABALEA
-
podoclaste: casse-pieds

__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea


Tamir,

What are you talking about?
DER encoding doesn't say anything about how the length of RSA key 
elements compare to each others.


Read X.690 again, and PKCS#1 also. If you still come with the same 
conclusion, re-read again, and again, and again.


Le 02/04/2012 17:09, Tamir Khason via RT a écrit :

Erwann, Peter
This is right, but all numbers are integers and should be encodeed
accordingly. If encoding assuming fixed size integers, it should use
length octets, if not end-of-contents octets. At least this is how i
read 8.1 from ASN.1 spec
(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).
This is why i think there is a bug in ASN.1 encoding of the
certificate



--
Erwann ABALEA
-
nosovermiculotracter: interroger

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea via RT

Tamir,

What are you talking about?
DER encoding doesn't say anything about how the length of RSA key 
elements compare to each others.

Read X.690 again, and PKCS#1 also. If you still come with the same 
conclusion, re-read again, and again, and again.

Le 02/04/2012 17:09, Tamir Khason via RT a écrit :
 Erwann, Peter
 This is right, but all numbers are integers and should be encodeed
 accordingly. If encoding assuming fixed size integers, it should use
 length octets, if not end-of-contents octets. At least this is how i
 read 8.1 from ASN.1 spec
 (http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).
 This is why i think there is a bug in ASN.1 encoding of the
 certificate


-- 
Erwann ABALEA
-
nosovermiculotracter: interroger


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea


Tamir,

DER encoding forbids you to use end-of-content octets. PKCS#1 defines 
RSA key elements, and doesn't say that exponent1, exponent2 and 
coefficient to be the same size.


If you still think you have found a bug in OpenSSL encoding of an RSA 
private key, please send this object (in its PEM format) to the list, 
together with explanations of where you think the errors are.


From what I've seen on your blog, and your answers here, it appears 
that an incomprehension of the situation on your side is transformed 
into an hypothetic bug in OpenSSL. Send the object you're talking about, 
consider the private key no longer private, and you'll receive some help 
and explanations.


Le 02/04/2012 18:34, Tamir Khason via RT a écrit :

maybe i am failed to explain myself.
DER encoding says how to encode numbers, RSA key elements define what
are those number. So integers from RSA key, should be encoded
according ANS1 DER encoding, which means should be have either length
octets or end-of-contents octets

On Mon, Apr 2, 2012 at 6:56 PM, Erwann Abalea via RTr...@openssl.org  wrote:

Tamir,

What are you talking about?
DER encoding doesn't say anything about how the length of RSA key
elements compare to each others.

Read X.690 again, and PKCS#1 also. If you still come with the same
conclusion, re-read again, and again, and again.

Le 02/04/2012 17:09, Tamir Khason via RT a écrit :

Erwann, Peter
This is right, but all numbers are integers and should be encodeed
accordingly. If encoding assuming fixed size integers, it should use
length octets, if not end-of-contents octets. At least this is how i
read 8.1 from ASN.1 spec
(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).
This is why i think there is a bug in ASN.1 encoding of the
certificate




--
Erwann ABALEA
-
piperonatriohirsutisme: le charme de la quarantaine

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea via RT

Tamir,

DER encoding forbids you to use end-of-content octets. PKCS#1 defines 
RSA key elements, and doesn't say that exponent1, exponent2 and 
coefficient to be the same size.

If you still think you have found a bug in OpenSSL encoding of an RSA 
private key, please send this object (in its PEM format) to the list, 
together with explanations of where you think the errors are.

 From what I've seen on your blog, and your answers here, it appears 
that an incomprehension of the situation on your side is transformed 
into an hypothetic bug in OpenSSL. Send the object you're talking about, 
consider the private key no longer private, and you'll receive some help 
and explanations.

Le 02/04/2012 18:34, Tamir Khason via RT a écrit :
 maybe i am failed to explain myself.
 DER encoding says how to encode numbers, RSA key elements define what
 are those number. So integers from RSA key, should be encoded
 according ANS1 DER encoding, which means should be have either length
 octets or end-of-contents octets

 On Mon, Apr 2, 2012 at 6:56 PM, Erwann Abalea via RTr...@openssl.org  wrote:
 Tamir,

 What are you talking about?
 DER encoding doesn't say anything about how the length of RSA key
 elements compare to each others.

 Read X.690 again, and PKCS#1 also. If you still come with the same
 conclusion, re-read again, and again, and again.

 Le 02/04/2012 17:09, Tamir Khason via RT a écrit :
 Erwann, Peter
 This is right, but all numbers are integers and should be encodeed
 accordingly. If encoding assuming fixed size integers, it should use
 length octets, if not end-of-contents octets. At least this is how i
 read 8.1 from ASN.1 spec
 (http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).
 This is why i think there is a bug in ASN.1 encoding of the
 certificate



-- 
Erwann ABALEA
-
piperonatriohirsutisme: le charme de la quarantaine


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea


Le 02/04/2012 19:21, Tamir Khason via RT a écrit :

Please see attached good and bad example + plain dump for both


The attached file has been badly altered. It seems all 0x7f-0xff bytes 
have been transformed into '?'.


Just place the PEM content of your supposedly bad object in the body of 
a mail.


--
Erwann ABALEA
-
BC  Merci à tous de me plnnKER  que j'ai plus à vous supporter!
VR  Du coup, je l'ai déplonké, pour voir.
Tiens, moi il est passé de -1000 à -100...
-+- ED in GNU : La constante de plonk en solde à -100 -+-

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer

2012-04-02 Thread Erwann Abalea via RT

Le 02/04/2012 19:21, Tamir Khason via RT a écrit :
 Please see attached good and bad example + plain dump for both

The attached file has been badly altered. It seems all 0x7f-0xff bytes 
have been transformed into '?'.

Just place the PEM content of your supposedly bad object in the body of 
a mail.

-- 
Erwann ABALEA
-
BC  Merci à tous de me plnnKER  que j'ai plus à vous supporter!
VR  Du coup, je l'ai déplonké, pour voir.
Tiens, moi il est passé de -1000 à -100...
-+- ED in GNU : La constante de plonk en solde à -100 -+-


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0

2012-03-05 Thread Erwann Abalea


Le 05/03/2012 15:14, Stephen Henson via RT a écrit :

[steve - Fri Mar 02 03:57:59 2012]:


[to...@tutus.se - Thu Mar 01 15:44:36 2012]:

Hi,

In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as

84 00 00 00 00

at the end of a block to be parsed, it will give header too long error
even though the ASN.1 is valid.

The last time I looked that wasn't a valid encoding. The length must be
expressed in the minimum number of octets possible, that applies to BER
as well as DER.


Hmm... must have confused it with something else. That *is* legal.



No, you were (partly) right. This is legal BER, not DER.

--
Erwann ABALEA
-
parturiophone: enceinte acoustique

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0

2012-03-05 Thread Erwann Abalea via RT

Le 05/03/2012 15:14, Stephen Henson via RT a écrit :
 [steve - Fri Mar 02 03:57:59 2012]:

 [to...@tutus.se - Thu Mar 01 15:44:36 2012]:

 Hi,

 In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
 parser that if one has length data such as

 84 00 00 00 00

 at the end of a block to be parsed, it will give header too long error
 even though the ASN.1 is valid.
 The last time I looked that wasn't a valid encoding. The length must be
 expressed in the minimum number of octets possible, that applies to BER
 as well as DER.

 Hmm... must have confused it with something else. That *is* legal.


No, you were (partly) right. This is legal BER, not DER.

-- 
Erwann ABALEA
-
parturiophone: enceinte acoustique


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779

2011-09-11 Thread Erwann ABALEA

Hodie III Id. Sep. MMXI, Peter Sylvester scripsit:
On 09/11/2011 12:12 AM, Erwann ABALEA wrote:
 
  Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit:
 
  According to rfc1779, the key STREET in the subject name should be 
 capitalized.
 
  obj_dat.h specifies it as a lower-cased street.
 
  This is incorrect and breaks when OpenSSL is used to parse in 
 rfc1779-compliant distinguished names generated by external parties.
 
  The solution is to upper-case it to STREET, just like C, CN, etc.
 
  The street attribute type (OID 2.5.3.9) is not defined by RFC1779.
  This RFC doesn't state that those tokens are case sensitive (you could
  even use cn instead of CN).
  This RFC is defective at least in one aspect: the following names are
  not considered equal:
CN=James Bond, O=MI6, C=UK
CN=James \ Bond, O=MI6, C=UK
CN=\ \ jAmeS bonD, O=MI6, C=UK
  these examples are equal, following X.520 rules.
 
 
Hm,
 
  OID 2.5.3.9 is id-at-streetAddress OBJECT IDENTIFIER ::= {[1]id-at 9}
 
  streetAddress [2]ATTRIBUTE ::= {
WITH SYNTAX   [3]UnboundedDirectoryString
EQUALITY MATCHING RULE[4]caseIgnoreMatch
SUBSTRINGS MATCHING RULE  [5]caseIgnoreSubstringsMatch
ID[6]id-at-streetAddress
  }
 
  In  1779
 
 CN  CommonName
 L   LocalityName
 ST  StateOrProvinceName
 O   OrganizationName
 OU  OrganizationalUnitName
 C   CountryName
 STREET  StreetAddress
 
  rfc 4514 has
 
CN  commonName (2.5.4.3)
L   localityName (2.5.4.7)
ST  stateOrProvinceName (2.5.4.8)
O   organizationName (2.5.4.10)
OU  organizationalUnitName (2.5.4.11)
C   countryName (2.5.4.6)
STREET  streetAddress (2.5.4.9)
DC  domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
 
in objects.txt
 
X509 3            : CN      : commonName
X509 6            : C            : countryName
X509 7            : L            : localityName
X509 8            : ST            : stateOrProvinceName
X509 9            : street        : streetAddress
X509 10            : O            : organizationName
X509 11            : OU            : organizationalUnitName
 
IMO should be STREET
 (but existing  req etc config files should become broken)
 
the rfc doesn't treat equality or matching.
the rfc describes a textual representation of an encoded name.
not any kind of canonical or distinguished form.

If the OP is concerned by a mismatch between street and STREET
then I guess his question concerns matching strings.

The OP also complains that OpenSSL has a problem parsing
RFC1779-compliant DNs. In fact, OpenSSL doesn't parse RFC1779 names.
It has its own format.

btw your examples seem wrong to me, a space cannot escaped by \
as far as I understand rfc 1779

I could have used quotes, yes, but escaping is valid (yet ugly).

-
The quoting mechanism is used for the following cases:

   o  Strings containing ,, +, = or  , CR, ,
  , #, or ;.

   o  Strings with leading or trailing spaces

   o  Strings containing consecutive spaces
-

Quoting is defined as prefixing the character with a \, or enclosing
the whole string in a  pair, or both (is the string also contains
 characters).

  rfc 4514 has  ' ', '', '#', '+', ',', ';', '', '=', '', or '\'

And RFC4519 names the attribute 'street', and all others in lowercase.

The  textual representations
 
  CN=   jAmes bonD
  CN=James  Bond
 
designate different encodings that match, i.e. 
only one could be in a directory.

Yes, as cn=James Bond, i.e. the case of the directory attribute name
is not important.

Test it an LDAPv3-compliant LDAP server, and you'll be able to use
both forms (lower and upper case) for the directory attributes. You
may even be able to use the OID form. Same with the certificateMatch
filter, if your LDAP server supports it.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779

2011-09-10 Thread Erwann ABALEA

Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit:
 According to rfc1779, the key STREET in the subject name should be 
 capitalized.
 
 obj_dat.h specifies it as a lower-cased street.
 
 This is incorrect and breaks when OpenSSL is used to parse in 
 rfc1779-compliant distinguished names generated by external parties.
 
 The solution is to upper-case it to STREET, just like C, CN, etc.

The street attribute type (OID 2.5.3.9) is not defined by RFC1779.
This RFC doesn't state that those tokens are case sensitive (you could
even use cn instead of CN).
This RFC is defective at least in one aspect: the following names are
not considered equal:
  CN=James Bond, O=MI6, C=UK
  CN=James \ Bond, O=MI6, C=UK
  CN=\ \ jAmeS bonD, O=MI6, C=UK
these examples are equal, following X.520 rules.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] openssl.org web site certificate renewed

2011-08-30 Thread Erwann ABALEA

Bonjour,

Hodie III Kal. Sep. MMXI, Lutz Jaenicke scripsit:
 I have just installed a new 3 year wildcard *.openssl.org certificate
 to our web site.
 Thanks to GlobalSign for the new donation.
 
 The migration should work more or less unnoted for the users. If you
 experience any problems please drop me a message.

Thanks to them, yes.

Maybe you could remove the root CA from file designed by the
SSLCertificateChainFile directive? It's useless to send it to the
client, as you know, and you may gain 1 TCP packet (+ ACK in return)
during the negotiation.

You should also disable SSLv2, and 128bits ciphers.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Bug in decoding/printing the authorityKeyIdentifier extension

2011-08-26 Thread Erwann ABALEA

Bonjour,

Given a certificate with an authorityKeyIdentifier extension
containing the issuerName and serial fields, with a negative serial
number, displaying this certificate (openssl x509 -text -noout ...)
doesn't tell that the serial number is negative, and prints its
absolute value.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: Verify X.509 certificate, openssl verify returns bad signature

2010-08-30 Thread Erwann ABALEA

Hodie IV Kal. Sep. MMX, Mounir IDRASSI scripsit:
[...]
 Specifically, Peter Gutmann in his X.509 Style Guide says this about this
 field : If you're writing certificate-handling code, just treat the
 serial number as a blob which happens to be an encoded integer.

This is the kind of advice that pushes programmers to allocate fixed
size fields in databases, and consider a certificate's serial number
to always fit the size. This is also bad in practice.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: How to locate the X.509 specifications

2010-08-09 Thread Erwann ABALEA

Hodie VI Id. Aug. MMX, David Shambroom scripsit:
 RFC 5280 is just what it says it is:
 
 Internet X.509 Public Key Infrastructure Certificate and
 Certificate Revocation List (CRL) Profile

Exactly. And Kyle was explaining where to find the X.509
specification.

 tailored for the Internet (Section 3.1)  No one said that it's
 anything more.  Don't use it if you don't like it, but it's worth
 knowing about.

I'm forced to use it, since that's what most systems refer to when
they want X.509 certificates.

You're right, it's worth knowing about. But in addition to the real
X.509 standard.

[...]
 Kyle Hamilton wrote:
 I was asked this morning where to find the X.509 specification,
 since http://itu.int/ is such a messy website.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France
Tél.: +33 1 55 64 22 07
http://www.keynectis.com
-
Aiming at foot before pulling trigger always bad idea.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: How to locate the X.509 specifications

2010-08-08 Thread Erwann ABALEA

Hodie VII Id. Aug. MMX, David Shambroom scripsit:
 See:
 
 http://www.ietf.org/rfc/rfc5280.txt

RFC5280 is only a profile for X.509 certificates and CRLs, just were
RFC3280 and RFC2459 before it. Hopefully, RFC5280 is of better quality
than its predecessors, but doesn't replace the standard at all.
It adds more constraints, some of them are unnecessary (for example an
organizationName or a commonName limited to 64 characters).

RFC acts on top of X.509, and only for public key certificates (i.e.
not attribute certificates).

 Kyle Hamilton wrote:
 I was asked this morning where to find the X.509 specification,
 since http://itu.int/ is such a messy website.

It's sad the 2008 version is only available for a fee.
I always thought the free 2005 version (and corresponding X.5xx
standards covering other important aspects) was a good thing to help
development.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
Département RD
KEYNECTIS
11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France
Tél.: +33 1 55 64 22 07
http://www.keynectis.com
-
scanf() is evil.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Stuck in France...

2010-04-19 Thread Erwann ABALEA

Hodie XIII Kal. Mai. MMX, Richard Levitte scripsit:
 Just a heads up...
 
 I'm stuck in France due to ashes in the air.  Most of my energy has
 been spent on trying to figure out how to get back to Sweden as soon
 as possible, instead of, as I had hoped, working on stuff such as the
 VMS build of OpenSSL...
 
 *sigh*

Sorry for this. These are security measures, as volcano ashes are very
abrasive for engines.
If you're in Paris, I'd be glad to offer you a beer or two, just
contact me off-list.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
It takes 43 muscles to frown and 17 to smile, but it doesn't take any
to just sit there with a dumb look on your face.
  Demotivators, 2002 calendar
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-11 Thread Erwann ABALEA

Hodie VII Id. Mar. MMX, Dr. Stephen Henson scripsit:
 On Tue, Mar 09, 2010, Erwann ABALEA wrote:
 
  I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
  few days ago (German passports), with the same error
  (d2i_ECPKParameters function).
  
  The verification of the root against itself is OK, though.

 Well that doesn't check the signature any more unless you include 
 -check_ss_sig

Hmmm... Thanks, this option doesn't appear in the help text.

  Of course, the verification of a subordinate certificate against the
  root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.
 
 That's odd they both verify fine here.
 
 Do you have any of the old patch code in place? I ended up using a completely
 different technique in HEAD.

You were right, I certainly still had some of the old patch. With a
new version freshly exported and compiled, everything's fine, both
RSASSA-PSS and ecdsa-with-SHA256. Thanks.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
When uncertain, or in doubt, run in circles and scream.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature

2010-03-09 Thread Erwann ABALEA

Hodie post. Non. Mar. MMX, Stephen Henson via RT scripsit:
 I've now committed code to the development branch which includes PSS
 signature verification support. I'll look into PSS signing at some point
 too.
 
 Let me know of any problems.

I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a
few days ago (German passports), with the same error
(d2i_ECPKParameters function).

The verification of the root against itself is OK, though.

Of course, the verification of a subordinate certificate against the
root is/was OK with the Feb 7 version, without the RSASSA-PSS patch.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: Applying the RSASSA-PSS patch

2010-02-26 Thread Erwann ABALEA

Bonjour,

Hodie V Kal. Mar. MMX, Martin Kaiser scripsit:
 thanks for testing my patch and giving feedback.

You're welcome. Thanks for working on integrating rsassapss.

[...]
 I've just downloaded the pss certificates you provided and confirmed
 that they verify ok. Could you by any chance send me the ecdsa
 certificates that cause problems with the patch? I guess I'll have some
 time middle of next week to look into this.

Here's the actual German CSCA certificate:
-BEGIN CERTIFICATE-
MIIDfzCCAySgAwIBAgICAR0wDAYIKoZIzj0EAwIFADBPMQswCQYDVQQGEwJERTEN
MAsGA1UECgwEYnVuZDEMMAoGA1UECwwDYnNpMQwwCgYDVQQFEwMwMTMxFTATBgNV
BAMMDGNzY2EtZ2VybWFueTAeFw0wODAyMjYxMzQzMDRaFw0yMTA4MjYxMjM1NTZa
ME8xCzAJBgNVBAYTAkRFMQ0wCwYDVQQKDARidW5kMQwwCgYDVQQLDANic2kxDDAK
BgNVBAUTAzAxMzEVMBMGA1UEAwwMY3NjYS1nZXJtYW55MIIBMzCB7AYHKoZIzj0C
ATCB4AIBATAsBgcqhkjOPQEBAiEAqftX26Huqbw+ZgqQnYONcm479iPVJiAoIBNI
HR9uU3cwRAQgfVoJdfwsMFfu9nUwQXr/5/uAVcEm3Fxs6UpLRPMwtdkEICbcXGzp
SktE8zC12bvXfL+VhBYpXPfhzmvM3Bj/jAe2BEEEi9Kuuct+V8ssS0gv/IG3r7ne
J+HjvSPCOkRTvZrOMmJUfvg1w9rE/Zf4RhoUYR3JwndFEy3tjlRcHVTHLwRplwIh
AKn7V9uh7qm8PmYKkJ2DjXGMOXqjtWGm95AeDoKXSFanAgEBA0IABEqUSYF3nd8d
pefFJ+J9JHGpKOtNe2d1rgkKUUUZm9R+oIHlXtSkP2B8alDuNkGKh//NphA5ypV2
fa7Kw0Q/4yyjggEQMIIBDDA2BgNVHREELzAtgRhjc2NhLWdlcm1hbnlAYnNpLmJ1
bmQuZGWGEWZheDorNDkyMjg5NTgyNzIyMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E
FgQUYETyRfLgcdTVZPTld9Y2advrGFkwHwYDVR0jBBgwFoAUYETyRfLgcdTVZPTl
d9Y2advrGFkwQQYDVR0gBDowODA2BgkEAH8ABwMBAQEwKTAnBggrBgEFBQcCARYb
aHR0cDovL3d3dy5ic2kuYnVuZC5kZS9jc2NhMBIGA1UdEwEB/wQIMAYBAf8CAQAw
KwYDVR0QBCQwIoAPMjAwODAyMjYxMzQzMDRagQ8yMDExMDIyNjEyMzU1NlowDAYI
KoZIzj0EAwIFAANHADBEAiAaOXEiepaq55JYiqXcC0iY6RelijCO0evRmhaXlOoE
5wIgKn5Ofpsi85jHKEkFGUlrc9XALkspq2WSKSlS85iUR/c=
-END CERTIFICATE-

And here's a DS certificate signed by this CSCA (ecdsa-with-SHA256):
-BEGIN CERTIFICATE-
MIIDGDCCArygAwIBAgICAUswDAYIKoZIzj0EAwIFADBPMQswCQYDVQQGEwJERTEN
MAsGA1UECgwEYnVuZDEMMAoGA1UECwwDYnNpMQwwCgYDVQQFEwMwMTMxFTATBgNV
BAMMDGNzY2EtZ2VybWFueTAeFw0wOTA0MzAxMzQ3MzJaFw0xOTEwMzAxMjMwNTBa
MEcxCzAJBgNVBAYTAkRFMR0wGwYDVQQKDBRCdW5kZXNkcnVja2VyZWkgR21iSDEM
MAoGA1UEBRMDMDYwMQswCQYDVQQDDAJEUzCCARMwgdQGByqGSM49AgEwgcgCAQEw
KAYHKoZIzj0BAQIdANfBNKomQ2aGKhgwJXXR14ewnwdXl9qJ9X7IwP8wPAQcaKXm
LKnObBwpmAOmwVMLUU4YKtiwBCpZytKfQwQcJYD2PM/kQTiHBxOxqSNp4z4hNdJm
27NyOGxACwQ5BA2QKa0sflz0NAgjsqh9xoyeTOMXTB5u/e4SwH1Yqlb3csBybyTG
uJ5OzawkNUuemcqj9tN2FALNAh0A18E0qiZDZoYqGDAlddD7mNEWvEtt3ryjpaeT
nwIBAQM6AAS5/ctMp7+KCOLmboOoD+Dlx4lDLX5XZWHycP4rOo+EgU2NqLqtMtgn
81c5tJe7aqMFqEejHBTVKaOB0TCBzjAOBgNVHQ8BAf8EBAMCB4AwHwYDVR0jBBgw
FoAUYETyRfLgcdTVZPTld9Y2advrGFkwQQYDVR0gBDowODA2BgkEAH8ABwMBAQEw
KTAnBggrBgEFBQcCARYbaHR0cDovL3d3dy5ic2kuYnVuZC5kZS9jc2NhMCsGCSqG
SIb3DQEJFQQeBBwxLjIuMjc2LjAuODAuMS4xMi4wLjIwLjUuMS4wMCsGA1UdEAQk
MCKADzIwMDkwNDMwMTM0NzMyWoEPMjAwOTA4MzAxMjMwNTBaMAwGCCqGSM49BAMC
BQADSAAwRQIgQYfwgQkqtEPTFWz+/vKQqH7ixuz/dqYbgkhxeisdcvQCIQCN5kAI
7TDnyDJpmli7Ci6cjOIZxNHLFUlV3fGX5JzaJg==
-END CERTIFICATE-

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
I'm not dyslexic, thank dog!
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Applying the RSASSA-PSS patch

2010-02-25 Thread Erwann ABALEA

Bonjour,

I need to be able to verify different real world certificates, some
of them signed using sha{1,256}withRSA, some using
ecdsa-with-SHA{1,256}, and some using rsassaPss.

For the sha*withRSA ones, the stable branch is OK.
For the ecdsa-with-SHA256 ones, I needed to download a development
version (0.9.8 branch doesn't support it).
And, for the rsassaPss ones, I needed to export a version dated 7
Feb 2010 version, and apply the proposed patch (I don't remember the
RT number). I performed a checkout from my local mirror of the OpenSSL
CVS repository (cvs co -D 7 feb 2010 external/openssl).

Applying the patch resulted in a positive and a negative effect:
 - I was able to verify the rsassaPss certificates
 - I wasn't able to verify ecdsa-with-SHA{1,256} certificates (yes,
   even SHA1 ones)

The error I get is the following:

error 7 at 0 depth lookup:certificate signature failure
3085249240:error:1009107F:elliptic curve 
routines:d2i_ECPKParameters:pkparameters2group failure:ec_asn1.c:1067:
3085249240:error:10090010:elliptic curve routines:d2i_ECParameters:EC 
lib:ec_asn1.c:1355:
3085249240:error:100D4010:elliptic curve routines:ECKEY_PARAM_DECODE:EC 
lib:ec_ameth.c:528:

I can provide certificates if necessary (those are passport
certificates from different countries)

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
All men can fly, but sadly, only in one direction -- down
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [PATCH]

2009-03-06 Thread Erwann ABALEA

Hello,

Hodie III Non. Mar. MMIX, Sune Rievers scripsit:
 Included are patches for OpenSSL 0.9.8j

[...]

 diff -u -p a/crypto/dso/dso_lib.c b/crypto/dso/dso_lib.c
 --- a/crypto/dso/dso_lib.c 2003-12-27 15:40:08.0 +0100
 +++ b/crypto/dso/dso_lib.c 2009-03-02 16:29:40.0 +0100
 @@ -400,8 +400,6 @@ char *DSO_merge(DSO *dso, const char *fi
 return(NULL);
 }
 if(filespec1 == NULL)
 -   filespec1 = dso-filename;
 -   if(filespec1 == NULL)
 {
 DSOerr(DSO_F_DSO_MERGE,DSO_R_NO_FILE_SPECIFICATION);
 return(NULL);

This one is interesting. It disallows the use of dso-filename. I
suppose it wasn't intended. Looks like a bug in Coccinelle to me.

Nothing is asserted on the value of dso-filename, one can only be
sure that dso isn't NULL.

Good job for a ladybug :) (that's what coccinelle means, in french).

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
OK to continue?  Yes No Maybe
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1854] GeneralizedTime support in openssl ca

2009-03-04 Thread Erwann ABALEA

Hi,

Hodie IV Non. Mar. MMIX, Oliver Martin via RT scripsit:
 This patch adds support for GeneralizedTime for startdate/enddate in
 openssl ca. I guess not too many people need certificates beyond 2049
 (or before 1950) right now, but having the capability surely can't hurt.
 
 Also, previously it accepted non-GMT times and values without seconds,
 both of which are not allowed by RFC 5280 (and previous ones). This is
 fixed too.
[...]

RFC5280 is a *profile* of X.509, i.e. a subset; it cannot replace
X.509.
Non Zulu times, minute accuracy, and fractional seconds are accepted
in X.509, why should it be refused by OpenSSL?

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
I t±ld yo±, Never±touch ±he flop±y disk s±rface!
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] [openssl.org #1854] GeneralizedTime support in openssl ca

2009-03-04 Thread Erwann ABALEA

Hodie IV Non. Mar. MMIX, Oliver Martin scripsit:
 Am Wed, 4 Mar 2009 11:19:09 +0100 schrieb Erwann ABALEA:
 
  RFC5280 is a *profile* of X.509, i.e. a subset; it cannot replace
  X.509.
  Non Zulu times, minute accuracy, and fractional seconds are accepted
  in X.509, why should it be refused by OpenSSL?
 
 Sorry, didn't know that. I looked for the full X.509 specification but
 couldn't find it - it seems I would have to buy it from ITU.

No, it is downloadable for free, as the other useful specifications
(X.501, X.520, X.680 and X.690 series). I have them downloaded from
their website, both in english and french, as PDF files.

 Does it allow GeneralizedTime for years between 1950 and 2049 too? Then

Yes, it does. There's no mention of a GeneralizedTime's use forbidden to
represent a date between 1950 and 2049.

-- 
Erwann ABALEA erwann.aba...@keynectis.com
-
If you never try anything new, you'll miss out on many of life's great
disappointments.
  Demotivators, 2002 calendar
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA isrenewed

2008-02-04 Thread Erwann ABALEA

Hi Dave,

Hodie Kal. Feb. MMVIII est, Dave Thompson scripsit:
  From: [EMAIL PROTECTED] On Behalf Of Erwann ABALEA
  Sent: Thursday, 31 January, 2008 13:08
 
  Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit:
 
   I disagree with this idea, in principle, and what you are suggesting is
 CA
   rekey, and not renewal.
  
   Renewal is when you issue a new certificate, but keep the same keys. In
 this
   case, the CRL validation in OpenSSL works fine, since the keys are the
 same,
   and the only difference in the cert is a new validity and serial number.
 
   In the case where a CA rekeys (new Private key) (which is hopefully not
 that
   often - since in any sort of production environment, this requires a
 full key
   ceremony, auditors, etc.)
 
  It has been done it this way with SET for years, every single CA had
  its private keys changed every year, and the corresponding
  certificates also. Even the root. And yes, it required a full key
  ceremony.
 
 IIRC SET used AuthorityKeyIdentifier extension in both (nonroot) certs and
 CRLs
 to identify the signer's verifying cert by Issuer+SN which is required
 unique.

Yes. I can't find where, but I think even the Root certificate has
this AKI extension. And in the SET specifications (part 2), it is
stated: 
A CA may have more than one certificate, either for functionally
different purposes, or as key updating occurs. This extension is used
to identify which CA certificate shall be used to verify the
certificate’s signature. Of course, one need to find the good issuer
certificate to be able to check the signature. But different private
keys associated to different certificates with the same subject name
form the same CA.

My point here was a reply to Patrick, saying that re-keying isn't done
in a production world. When we operated an SET platform, we (Certplus,
by then) managed one national brand, one geopolitical brand (Carte
Bleue, which is VISA in France), and several banks (8) under MCI and
VISA, delivering certificates for merchants, cardholders, and payment
gateways. Every single year, a key ceremony was done to renew all
these certificates, and generate the corresponding private keys. With
role separation (CRLSign, CertSign, Encryption, MessageSigning), IIRC,
that represented up to 80 certificates + private keys. And it was
designed to be done that way. Even the Root.

 This works even during overlap while the CA-signer has multiple certs valid,
 or (as also noted) different (keypairs and) certs for certsign versus
 crlsign.

Yes. For example, a PCA (Payment Gateway CA) has a certsigning certificate
valid for 2 years, with an associated private key valid for 1 year. It
can deliver payment gateway certificates valid for up to 1 year, and
be able to revoke these certificates anytime during their whole life.
Here's an extract of the X.509 standard:
The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
certificate, i.e. publish revocation data.

Imagine now the PCA1 certificate (the CA is PCA, and the generation
is 1). Its certificates are valid from 01/01/2000 to 01/01/2002, its
private keys are valid from 01/01/2000 to 01/01/2001. It delivers a PG
certificate on 12/31/2000, valid to 12/31/2001. This PCA1 can't revoke
this PG certificate after 01/01/2001, because it won't be able to sign
the CRL. But the PCA in itself (that includes all generations of this
CA) has to maintain the status of this PG certificate. So PCA2 (whose
certificates validity dates range from 01/01/2001 to 01/01/2003, and
private keys from 01/01/2001 to 01/01/2002) can revoke it, since it's
the same CA (CA=name).

The solution presented by Santosh on the 2004 thread mentioned by
Patrick doesn't work when privateKeyUsagePeriod extensions are used.

 I don't recall if AKI is present in their root certs, but it isn't needed,
 since a rootcert is signed by itself not any other (earlier or later)
 keypair
 for the root, and (of course) is trusted based on other information:
 the initially used root from out-of-band, and normal subsequent roots
 from a forward-chaining hash in another extension whose name I forget.

hashedRootKey :)
A pretty clever mechanism, in my opinion. The hash of the public key
of the next generation Root was included as an extension.

-- 
Erwann ABALEA [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed

2008-02-01 Thread Erwann ABALEA

Hi Patrick,

Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit:
 Hi Erwann;
 
 On Thursday 31 January 2008 13:07:32 Erwann ABALEA wrote:
   Renewal is when you issue a new certificate, but keep the same keys. In
   this case, the CRL validation in OpenSSL works fine, since the keys are
   the same, and the only difference in the cert is a new validity and
   serial number.
 
  OK. Let's call it rekey if you want, that's not a problem. We're a PKI
  operator, and we don't renew CAs, we only rekey them, then.
  Such differenciation is found nowhere in the X.509 standard, or the
  RFC3280 document (or its successor, still in draft).
 
 No, since this is a policy decision, the relevant document is RFC3647, which 
 makes a clear distinction between renewal and rekey.

Ok. Again, an RFC, of type Informational. So my argument still stands,
the standards (and I include RFC3280 here even if it's not a standard,
but a common practice) don't differentiate the rekey vs renew of a
CA. And this has nothing to do with CRL validation.

   One has to be very carefull when dealing with another CA that has the
   same name but different keys, or else it would be possible for an
   attacker to impersonate a CA.
 
  That's not possible. If it has the same name, then it's the same exact
  CA. Period.
  We're dealing here with CA certificates, with off-band verification to
  perform trust, etc. So CA impersonification is not a problem here.
 
 Please see this thread:
 
 http://www.imc.org/ietf-pkix/old-archive-04/msg01204.html

I've read the whole thread, thanks.

 Essentially, my take on what Santosh is saying is that CRLs need to be signed 
 by both CAs during the transition, because either a CA is active (and can 
 be used to validate the signature on the certificate itself) or it isn't. If 
 it is active it should sign it's own CRLs (and he doesn't preclude someone 
 else signing a CRL as well for that certificate, but if you do do this, then 
 the algorithm that he proposes in the thread should be followed, which 
 Stephan had a problem with, since there is a possible disambiguation problem 
 that could be exploited by a malicious attacker.).
 
 The relevant quote is as follows: Each of the two keys
 should be used to sign the full CRL for the scope of all certificates issued
 by that CA under all keys.  Furthermore, the same revoked certificate list
 (empty or not) should be signed with all active keys.  Active keys are
 defined as those CA private keys whose companion public keys can still be
 used to verify signatures on the certificates

What Santosh proposes here is biased, he wants to propose a solution
to allow even non-comformant relying parties to be able to handle this
specific case (re-key), with the MSCAPI example in head.

But on the same thread, he clearly describes what should be done in
the absence of IDP extensions, and the fact that a new CA key can sign
the whole CRL for the whole population (without requiring the old CA
key to do the same), etc.

I can only redirect you to annex B of the X.509 standard, which is
normative.

Anyway, right now, the solution proposed by Santosh doesn't work with
OpenSSL. OpenSSL refuses to load 2 CRLs with the same issuername in
the same store. Make your tests. And that's normal, from my point of
view, if we don't consider the CRLDP+reason extension.
My proposed patch handles this case also (again, it doesn't check the
reason flag of the optional CRLDP extension).

 So you can't just stop using a particular CA's keys... until it either 
 expires 
 or is revoked, it should keep issuing CRL's for the keys it has issued. And 
 if it keeps issuing CRL's, the situation for which you have created the patch 
 should never happen :).

That point of view should obviously be changed after reading the rest
of Santosh's posts, and the X.509 standard.

 This is a rather murky subject, and the merits of the two approaches are 
 probably best discussed on the PKIX list, rather than here, as the approach 
 has little to do with the technical implementation of what you propose :)

I agree CRL validation *can* be really chiant (sorry, my english
vocabulary doesn't allow me to express those things). But without
cRLIssuer, or IDP, or any fancy extensions, it can be handled quite
easily.


Regards,

-- 
Erwann ABALEA [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Proposed patch to check a CRL when a CA is renewed

2008-01-31 Thread Erwann ABALEA

Hello,

OpenSSL doesn't cleanly verify revocation status when a CA is renewed
(with a key change). Attached is a proposed patch to handle this case.
This patch has been done against the current CVS version (I mirror it
every night).

For a description of the problem, please consider the following
situation:
 * a CA (name it CN=My Trusted CA for example) is created, delivers
   certificates, revokes some, and periodically generates CRLs
 * this CA will expire in 1 year, so for service continuity (end-users
   certificates have a 1-year validity period), it has to be renewed
 * a new keypair is generated, a new certificate for this CA is
   produced (we *MUST* keep the same name to make it be the same CA)
 * this new CA certificate is deployed across the end-users base, and
   now this new generation CA does the job: certificate generation,
   revocation, CRL signing, etc), and the end-user certificates
   previously revoked by the old generation CA will be present in the
   CRL produced by this new generation CA

So the only CRL to have is the new one (the old generation CA doesn't
sign anything anymore).
OpenSSL can't verify old end-user certificates against the CRL,
because it checks the verification of the CRL against the public key
of the certificate that signed the end-user certificate. That's not
conformant to the X.509 standard.

-- 
Erwann ABALEA [EMAIL PROTECTED]


openssl099-crl-renewedca.diff.gz
Description: Binary data

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed

2008-01-31 Thread Erwann ABALEA

Hi Patrick,

Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit:
 Hi Erwann:
 
 On Thursday 31 January 2008 11:23:57 Erwann ABALEA wrote:
  Hello,
 
  OpenSSL doesn't cleanly verify revocation status when a CA is renewed
  (with a key change). Attached is a proposed patch to handle this case.
  This patch has been done against the current CVS version (I mirror it
  every night).
 
  For a description of the problem, please consider the following
  situation:
   * a CA (name it CN=My Trusted CA for example) is created, delivers
 certificates, revokes some, and periodically generates CRLs
   * this CA will expire in 1 year, so for service continuity (end-users
 certificates have a 1-year validity period), it has to be renewed
   * a new keypair is generated, a new certificate for this CA is
 produced (we *MUST* keep the same name to make it be the same CA)
   * this new CA certificate is deployed across the end-users base, and
 now this new generation CA does the job: certificate generation,
 revocation, CRL signing, etc), and the end-user certificates
 previously revoked by the old generation CA will be present in the
 CRL produced by this new generation CA
 
  So the only CRL to have is the new one (the old generation CA doesn't
  sign anything anymore).
 
 I disagree with this idea, in principle, and what you are suggesting is CA 
 rekey, and not renewal.

 Renewal is when you issue a new certificate, but keep the same keys. In this 
 case, the CRL validation in OpenSSL works fine, since the keys are the same, 
 and the only difference in the cert is a new validity and serial number.

OK. Let's call it rekey if you want, that's not a problem. We're a PKI
operator, and we don't renew CAs, we only rekey them, then.
Such differenciation is found nowhere in the X.509 standard, or the
RFC3280 document (or its successor, still in draft).

 In the case where a CA rekeys (new Private key) (which is hopefully not that 
 often - since in any sort of production environment, this requires a full key 
 ceremony, auditors, etc.)

It has been done it this way with SET for years, every single CA had
its private keys changed every year, and the corresponding
certificates also. Even the root. And yes, it required a full key
ceremony.
And even now, for a big customer we have in common (I won't give its
name here), such practice (renew of a CA certificate without
changing the private key) is strictly forbidden by its certification
policy.

The fact that it requires a full key ceremony is of no influence here,
as you also need to perform the key ceremony in the same conditions if
you renew a CA certificate.

 then your patch is applicable, but needs too be 
 examined in light of the other issues around certificate rekey... 

Sure, that's why this patch is only proposed, not imposed.

 One has to be very carefull when dealing with another CA that has the same 
 name but different keys, or else it would be possible for an attacker to 
 impersonate a CA.

That's not possible. If it has the same name, then it's the same exact
CA. Period.
We're dealing here with CA certificates, with off-band verification to
perform trust, etc. So CA impersonification is not a problem here.

 That is why, most of the time, CA keys are long life - I 
 normally see 20 years as usual lifetimes. In my experience key roll-over is 
 usually managed by some form of overlap - where the new Issuance CA is 
 brought up at a time that is the same as the validity period for currently 
 issued certs before the current CA end of lifes, and starts issuing certs 
 then, so that when the old CA finally goes out of validity, there are 
 no valid certs left around to issue CRLs for.

In what I wrote, which word wasn't clear? That's what we do, we
generate a new CA certificate at a time that is the same as the
validity period for currently issued certs before the current CA end
of lifes, and it starts issuing certs then. Here, we just happen to
generate a new private key for this CA.

The problem here is between this exact moment and the end-of-life of
the previous CA cert, some end-user certificates exist, are still
valid, and must be checked against a CRL signed by a different key
(but the same CA).

  OpenSSL can't verify old end-user certificates against the CRL,
  because it checks the verification of the CRL against the public key
  of the certificate that signed the end-user certificate. That's not
  conformant to the X.509 standard.
 
 I definitely disagree with the last statement - according to RFC3280 (which 
 is 
 the relevant X.509 standard in this case, I believe) if you want to 
 validate a CRL against a key other than that used to sign the certificate, 
 you are supposed to use the cRLIssuer field of the cRLDistributionPoint in 
 the certificate. Allowing any other form of validation of a CRL signature 
 leaves you wide open to a denial of service attack.

No. Neither the RFC3280 (which is only an X.509 profile

Re: [openssl-dev] Regarding extended key usage extension implementation which differs from RFC 2459

2007-06-08 Thread Erwann ABALEA

Bonsoir,

Hodie VI Id. Iun. MMVII est, durgaprasad jammula scripsit:
 This question is regarding the extended key usage
 extension implementation which differs from the
 specification [RFC 2459].
 
 I read RFC 2459 in
 http://www.faqs.org/rfcs/rfc2459.html section 4.2.1.13
  Extended key usage field. 

The corresponding paragraph of the RFC3280 (RFC2459 is obsolete, and
superseded by RFC3280) reads:

If the extension is present, then the certificate MUST only be used
 for one of the purposes indicated.

RFC3280 is much more clear and unambigous than RFC2459.

-- 
Erwann ABALEA [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Mail System Error - Returned Mail

2004-07-27 Thread erwann . abalea

Bonjour,

Je suis en congés jusqu'au 9 août inclus, je lirai donc votre
message à mon retour. En cas d'urgence, merci de contacter
Dominique Manenc [EMAIL PROTECTED].

Vous ne recevrez ce message qu'une seule fois.

Merci.


Hello,

I'm on vacation until august, the 9th, then I'll read your mail.
If necessary, please contact Dominique Manenc [EMAIL PROTECTED].

You'll receive this message only once.

Thanks.


-- 
Erwann ABALEA [EMAIL PROTECTED]
-
It takes months to find a customer, but only seconds to lose one...
The good news is that we should run out of them in no time.
  Demotivators, 2001 calendar
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl-dev] [openssl.org #551] [Fwd: Bug#186487: openssl:'openssl ca' allows serial 00 which breaks the signed certificate]

2003-04-04 Thread Erwann Abalea

On Thu, 27 Mar 2003, Richard Levitte via RT wrote:

 Something to note, however, is that the CA certificate usually has
 serial number 0, at least when creating it with OpenSSL the way it's
 usually described.  Therefore, there may be problems verifying, since
 the serial number 0 will be in two cerificates, and certificates are
 sometimes accessed as issuer+serial (to get the exact certificate)
 instead of subject. In the case where the CA cert and one of the issued
 certs have the same serial number, issuer+serial will lead to both of
 them, which in this case is an error.  However, that's a user error
 rather than an OpenSSL one, since CA certs can, technically have any
 serial number, just as any other certificate...

It's not a user error, it's a CA error, since the serial numbers of all
the certificates signed by a CA *must* be unique under this CA. This
includes also the CA itself, when it's a self-signed CA.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
If you never try anything new, you'll miss out on many of life's great
disappointments.
  Demotivators, 2002 calendar
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?

2002-11-13 Thread Erwann ABALEA

On Wed, 13 Nov 2002, Frédéric Giudicelli wrote:

 Well I hope MS will be able to get into an adult argumentation, I think it's
 mostly about the comprehension of the RFC, since it's really not clear the
 way IETF expresses it.
 The best solution would be that one of you big people, contact IETF, about
 the RFC comprehension, at least that would quit any kind of linguistic
 argumentation.

I personally don't think this would be useful. The corresponding paragraph
of the RFC3280 is more or less a copy of the text of the X.509 standard.
It is clearly stated at the beginning of this paragraph (the one of the
RFC3280, as not everyone has a copy of the X.509 right now) that:

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate.  This extension is used where an issuer has
   multiple signing keys (either due to multiple concurrent key pairs or
   due to changeover).  The identification MAY be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

So the purpose of this extension is to find 'the issuer of the present
certificate', and the remaining text should be placed on that context.
More precisely, when it is talked about 'the issuer name', one must
understand 'the issuer name of the issuer of the present certificate',
just as when it is talked about the 'keyIdentifier', one must understand
'the keyIdentifier of the issuer of the present certificate', and when it
is talked about 'the serial number', one must understand 'the serial
number of the issuer of the present certificate'.

RFCs-reading is an art, just like Standards-reading ;)

So far, I think that only Microsoft made this mistake, I never found it in
any other product I've seen.

Based on that, I really don't think it might be necessary to rewrite the
RFC, or the X.509 standard (which would involve *much* more work).

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
Unspeakable error in module Cthulhu at address R'lyeh.

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

Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?

2002-11-04 Thread Erwann ABALEA

On Thu, 31 Oct 2002, Frédéric Giudicelli via RT wrote:

 ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal)
 INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer 
(normal)
 A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer
 (not normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of
 this certificate is INTERMEDIATE CA and not ROOT CA.

OpenSSL is right. To use 'human' terms, to point to your father, you have
to give your grandfather's name and the exact number of your father among
all your grandfather's children. That's how it's done, and that's how it
has to be done.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour
fonctionner,à force,en France de refuser tout rapport sain avec
l'argent,l'on riqsque de tuer ce nouvel outil.
-+- AA in: Guide du Neuneu d'Usenet - Le netétiquette du riche -+-

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

Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?

2002-11-04 Thread Erwann ABALEA

On Sat, 2 Nov 2002, Vadim Fedukovich wrote:

 On Fri, Nov 01, 2002 at 12:51:24AM +0100, 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, Microsoft and openssl are not the only code available.
 Would you accept a well-done one from IBM? The SET wallet was tested
 to accept certificates hierarchy with AKI extension in merchant certificate
 referring brand CA, not merchant CA name.

You're right, that's how it's done in the SET hierarchy. The keyIdentifier
is not used, the only valid content for the authorityKeyIdentifier is the
issuer's name of the issuer certificate, packed with the issuer's
certificate serial number.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
Et puis, je sais que ça ne se fait pas de reprendre sur l'orthographe,
mais l'usage Usenetien veut qu'on écrive scançeur.
En ajoutant fâssiste, pour faire bonne mesure.
-+- XH in http://neuneu.mine.nu : L'heptalingue sans peine -+-

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

Re: [openssl.org #323] Bug in authorityKeyIdentifier extension ?

2002-11-04 Thread Erwann ABALEA

On Fri, 1 Nov 2002, [iso-8859-1] Frédéric Giudicelli 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. Since Microsoft's history if full of bugs, security problems, and
non-comformity to the standarts, then Microsoft is more likely to be
guilty. ;)

 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. The authorityKeyIdentifier can be used in 3 different manners,
differing in the content of the extension:
 1/ specify the keyIdentifier contained in the subjectKeyIdentifier
extension of the issuer certificate
 2/ specify the issuer name of the issuing certificate, with the serial
number of the issuing certificate (that is, identify the issuing
certificate by it's father's name and the rank of the issuing
certificate in all those children).
 3/ both of the above contents

The easiest method is the first one, of course. But that means each
issuing certificate has to have a subjectKeyIdentifier extension. When
it's not the case, and you *must* provide an authorityKeyIdentifier
extension, then the method 2 is the only one possible.

Please take into consideration that:
 - qualified certificates are defined by European directives, not a french
   law
 - it takes a lot more than just using the authorityKeyIdentifier
   extension to have a qualified certificate

Hope this helps.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
CJ Les censeurs agitent plus de vent que les moulins des Pays Bas.
Tiens, je savais pas que c'étaient les moulins qui créaient le vent.
-+- GR in GNU : Dame qui se shoote et sang chaud pensa -+-

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

Re: certificate start date difference!

2002-08-01 Thread Erwann ABALEA


On Mon, 8 Jul 2002, Mehdi Jabal Ameli wrote:

 when I sign a certificate , the start date of certificate is different from time of 
my computer?(about 3 hours diffrence)
 is this openssl bug?

My answer: maybe the time difference between your local time and GMT time
is about 3 hours...

What is stored in a certificate is a GMT time.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
Stupidity is no excuse for not thinking.

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

Re: certificate start date difference!

2002-08-01 Thread Erwann ABALEA


Sorry for this late delivery. It seems pipes can be filled with
old stuff sometimes. ;)

On Mon, 8 Jul 2002, Erwann ABALEA wrote:

 On Mon, 8 Jul 2002, Mehdi Jabal Ameli wrote:

[...]

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
J'aurai aimé savoir si en Norvège il y avait effectivement des panneaux
de signalisation sur les routes indiquant la présence éventuelle de
fantômes? Merci.
-+- DM in :GNU- Il y a quelque chose de pouri au royaume du neuneu -+-

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

Re: Questions about PKI

2002-05-02 Thread Erwann ABALEA


Hi Kevin,

First of all, you're addressing your request to a developper only
mailing-list (openssl-dev). That's bad.

Second point, it seems you didn't understand that OpenSSL is not a PKI
product in itself, built by a company. It's an open source API, developed
by volunteers within their spare free time.

Last point, I don't think that your teacher would like those volunteers to
do your job. If *they* fill in your Excel document, who will get the note?
Did you really understand what your teacher asked you to do?

On Thu, 2 May 2002, kevin sahki wrote:

   Mr or Mrs,


 I'm a sudent in network technologie at EPITA (a french computing school in Paris) 
and I'm in telecommunication specialisation. I've to do a report on PKI. More 
exactely my report deals about the comparaison of the different PKI solution.
 During my research, I've discovered your PKI products.
 I would like to know if you could help me sending me some technical documentations 
in order to compare your products with other PKI products.
 I think that there are 5 PKI families:
 - open products like OpenCA
 - products to build a in house PKI like Baltimore, Entrust...
 - integrated product like Windows 2000
 - outsourcing PKI infrastructure
 - certification autority who only deliver certification like enditrust or click and 
trust.
 During my research I have found different point to compare the PKI :
 - Certificate support
 - Revocation methods
 - Scalability
 - Security
 - PKI topologies
 - Registration mechanisms for all the functions (email, VPN, Web ...)
 - Directory support
 - Smart Card support
 - Key management
 - Interoperability
 - Algorithm supported
 In order to make easy this comparaison I have created a comparaison table.
 I've joined this Excel table (tableau_PKI.xls). I would be glade if you could fill 
it.


 Thank you for your time and your interest.
 I'm looking foreward to reading you.
 Yours sincerely


-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
Pour moi, que ce soit fr.rec.arts.musique.variete ou
fr.rect.arts.chansons, c négatif, parce que je considére pas
la musique comme un art,
-+- BenC in http://neuneu.mine.nu : Neuneu joue du pipo.

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

Re: problem OpenSA SSL

2002-04-18 Thread Erwann ABALEA


On Thu, 18 Apr 2002, xavier de CD and LP wrote:

 I don't know if this a bug but I advise you about my problem :

 I am running OpenSA on a Windows 2000 server.
 Since I have tried to launch the service with SSL it doesn't work.
 I get this error message on the prompt :
 syntax error on line 209 of d:/opensa/apache/conf/httpd.conf
 cannot load d:/opensa/apache/modules/mod_ssl.so into server : 126 le module 
spécifié est introuvable
 I thing everything is correctly set up and don't understand where it comes from.

* This is *not* the good mailing list:
  - this one is *not* related to OpenSA at all
  - this one is for OpenSSL developers only (not OpenSSL users)

* You *don't* have a bug, you have an error, and the error message is
  pretty easy to read and understand, as it is written in french, and you
  seem to be french (as me). Please look at the d:/opensa/apache/modules
  directory, and see if you can find a file named mod_ssl.so. If not,
  then carefully read your documentation, and correct your configuration
  file according to this documentation. My first guess is that you won't
  find a file named mod_ssl.so in this directory, but a file named
  mod_ssl.dll, and that changing the mod_ssl.so into mod_ssl.dll in
  the configuration file should do the trick.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
NT n'a pas pu initialiser le fichier de partage de la partition de
démarrage pour le vidage sur incident. Ceci est peut-être dû au fait
que le système ne dispose plus que de 3,8 Go de mémoire physique.
-+- Windows NT in GNU : Giga ou giga pas ? Si c'est comme ça, je me crashe.

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

Re: your mail

2002-04-04 Thread Erwann ABALEA


On Thu, 4 Apr 2002, yves daignaux wrote:

 a fatal error return happens :


 making all in crypto/sha...
 cc -I.. -I../../include -DTHREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune 
host -fast -readonly_strings -c sha_dgst.c
 Fatal:  Insufficient virtual memory to continue compilation.

I don't think sending this message to openssl-bugs is a good idea. It's
not a bug in the OpenSSL code.

Just read carefully the error message, and try to determinate the cause of
the error, then try to find a solution.

Hint: my understanding is that you don't have enough memory left.
I think a good solution would be to call the administrator.

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
BC désolé, mais j'ai pas pû m'empecher.
On a vu, mais bon, vraiment fallait pas, vous ne manquiez pas encore
assez.
-+- RM in http://neuneu.mine.nu : En période de manque -+-

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

Re: Solaris bc

2002-03-05 Thread Erwann ABALEA


On Mon, 4 Mar 2002, Michael Sierchio wrote:

 Daniel Sands wrote:

  What's the problem here?  The output is exactly as it should be for this
  program.

 Your lack of reading skills?  The point is that the previous
 poster asserted that dc was a front end to bc.  I believe that I
 conclusively demonstrated that this is not the case.  Try again.

Well... If I look at dc's man page, on my Solaris 8 station, here's what I
get in the Description paragraph:

 bc is a preprocessor for dc that provides infix notation and
 a  C-like syntax that implements functions. bc also provides
 reasonable control structures for programs. See bc(1).

dc and bc are linked by some way...

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
I'm not dyslexic, thank dog!

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

Re: Solaris bc

2002-03-05 Thread Erwann ABALEA


On Tue, 5 Mar 2002, Michael Sierchio wrote:

 Erwann ABALEA wrote:

  dc and bc are linked by some way...

 Yes.  Unlink dc and bc won't work. ;-)

;)

I read J.P. King's email, and it's more clear now.
ot
I should try to learn dc, as I'm more comfortable with RPN that
traditional algebraic.
/ot

-- 
Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5
-
OK to continue?  Yes No Maybe



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

Re: Please help me.

2001-10-11 Thread Erwann ABALEA


On Sat, 13 Oct 2001, Shai wrote:

 Can u help me?
 I have this error message:
 81431:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not 
seeded:md_rand.c:492:You need to read the OpenSSL FAQ, 
http://www.openssl.org/support/faq.html
 What libraries do i need to include to overcome this problem?

As stated in the error message, which you obviously didn't read at all
(shame on you), you should read the FAQ to overcome this problem. The URL
to get the FAQ is in the error message.

You shouldn't have sent a bug report for this. It's a bug in *your*
configuration or code, not a bug in the OpenSSL library.

-- 
Erwann ABALEA
[EMAIL PROTECTED]
RSA PGP Key ID: 0x2D0EABD5
-
``We're operating from a knowledge base that is not very dense.''
 Jim Skeen
Explaining how to say that we don't know what we are doing.

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

RE: PKCS#11 engine support

2001-05-03 Thread Erwann ABALEA


On Thu, 3 May 2001, Reddie, Steven wrote:

 Zoran, I'd be happy to test your implementation.  The PKCS#11 devices that I
 have at my disposal are:
   Eracom CSA7001/7002
   nCipher nFast SCSI HSM

   GemPlus PC410 smartcard reader
   Litronic Netsignia 210 smartcard reader

Please don't say that a smartcard reader is a PKCS#11 token... The token
is the smartcard, not the reader. I think you're talking about a GemSAFE
card accessed with a PC410 reader, right? You could use the same card with
the Litronic reader, as soon as you splitted the code between
reader-dependant and card-dependant. The best way to do this is to use the
PC/SC API.

 and I think there may be a Rainbow HSM and Rainbow iKey's floating around
 somewhere.

 I was gearing up to submit the OpenSSL/PKCS#11 integration that I've
 been developing/using for the last 18 months.  It works with the
 devices listed above, and the Rainbow CryptoSwift 300.  It's taken me
 this long to get approval from above.  I've only implemented RSA
 operations though, so perhaps yours is more complete.  Mine is
 implemented using the RSA_METHOD hook rather than as an ENGINE
 component, so yours may be more relevant.

 Regards,

 Steven

  -Original Message-
  From:   Zoran Radenkovic [SMTP:[EMAIL PROTECTED]]
  Sent:   Thursday, May 03, 2001 11:42 AM
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject:PKCS#11 engine support
 
  Hi,
 
  We are currently producing an OpenSSL/mod_ssl/Apache solution that uses
  our
  new h/w accelerator
  card CSA8000. This card talks to the host using PKCS#11 interface and it
  plugs-in to OpenSSL
  via engine API. Currently it supports 0.9.6 version (in next few days we
  will look
  in 0.9.6a as well). Engine support is completely PKCS#11 based (it's not
  h/w specific as other engines)
  and should work with any cryptoki implementation. We tested it with
  cryptoki for CSA7000, CSA8000
  adapters and s/w based cryptoki. We don't have available any non-Eracom
  cryptoki.
 
  We got approval from management to opensource this patch for openssl if
  there is an interest. It would
  be great if we can catch the train for 0.9.7. How far is it?
 
  I have few questions if we go further:
  a)   How much is engine API changed in 0.9.7. Will 0.9.6a port will work
  or
  is demanding significant
  change?
 
  b)   Does openssl development team have any means to test it with criptoki
  implementation.
  Because CSA8000 will be released in next few weeks it will be very hard to
  get handle to one adapter.
  We can maybe provide Eracom's s/w criptoki implementation for
  openssl-development team.
 
  c)   Is it sufficient to give you a patch for 0.9.6a or we need to port it
  on 0.9.7 shapshot  first.
 
 
  Cheers,
  Zoran Radenkovic
 
 
 
  ERACOM Products meeting today's security needs.
  Visit our Website at: http://www.eracom.com.au
  Or call ERACOM Pty. Ltd. on: +61 7 5593 4911
 
  __
  OpenSSL Project http://www.openssl.org
  Development Mailing List   [EMAIL PROTECTED]
  Automated List Manager   [EMAIL PROTECTED]
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   [EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]


-- 
Erwann ABALEA
[EMAIL PROTECTED]
RSA PGP Key ID: 0x2D0EABD5
-
When uncertain, or in doubt, run in circles and scream.

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

RE: PKCS#11 engine support

2001-05-03 Thread Erwann ABALEA


Anyway, I'd like to have a look at your work, since I also have some
smartcards (GemSAFE, GemPKCS, Schlumberger Cryptoflex) and other PKCS#11
tokens (Lunas from Chrysalis-ITS, and others).

I wanted to write some engines for these devices, but I don't have the
time to do it... :-(

On Thu, 3 May 2001, Erwann ABALEA wrote:

 On Thu, 3 May 2001, Reddie, Steven wrote:

  Zoran, I'd be happy to test your implementation.  The PKCS#11 devices that I
  have at my disposal are:
  Eracom CSA7001/7002
  nCipher nFast SCSI HSM

  GemPlus PC410 smartcard reader
  Litronic Netsignia 210 smartcard reader

 Please don't say that a smartcard reader is a PKCS#11 token... The token
 is the smartcard, not the reader. I think you're talking about a GemSAFE
 card accessed with a PC410 reader, right? You could use the same card with
 the Litronic reader, as soon as you splitted the code between
 reader-dependant and card-dependant. The best way to do this is to use the
 PC/SC API.

  and I think there may be a Rainbow HSM and Rainbow iKey's floating around
  somewhere.

  I was gearing up to submit the OpenSSL/PKCS#11 integration that I've
  been developing/using for the last 18 months.  It works with the
  devices listed above, and the Rainbow CryptoSwift 300.  It's taken me
  this long to get approval from above.  I've only implemented RSA
  operations though, so perhaps yours is more complete.  Mine is
  implemented using the RSA_METHOD hook rather than as an ENGINE
  component, so yours may be more relevant.
 
  Regards,
 
  Steven
 
   -Original Message-
   From: Zoran Radenkovic [SMTP:[EMAIL PROTECTED]]
   Sent: Thursday, May 03, 2001 11:42 AM
   To:   [EMAIL PROTECTED]
   Cc:   [EMAIL PROTECTED]
   Subject:  PKCS#11 engine support
  
   Hi,
  
   We are currently producing an OpenSSL/mod_ssl/Apache solution that uses
   our
   new h/w accelerator
   card CSA8000. This card talks to the host using PKCS#11 interface and it
   plugs-in to OpenSSL
   via engine API. Currently it supports 0.9.6 version (in next few days we
   will look
   in 0.9.6a as well). Engine support is completely PKCS#11 based (it's not
   h/w specific as other engines)
   and should work with any cryptoki implementation. We tested it with
   cryptoki for CSA7000, CSA8000
   adapters and s/w based cryptoki. We don't have available any non-Eracom
   cryptoki.
  
   We got approval from management to opensource this patch for openssl if
   there is an interest. It would
   be great if we can catch the train for 0.9.7. How far is it?
  
   I have few questions if we go further:
   a)   How much is engine API changed in 0.9.7. Will 0.9.6a port will work
   or
   is demanding significant
   change?
  
   b)   Does openssl development team have any means to test it with criptoki
   implementation.
   Because CSA8000 will be released in next few weeks it will be very hard to
   get handle to one adapter.
   We can maybe provide Eracom's s/w criptoki implementation for
   openssl-development team.
  
   c)   Is it sufficient to give you a patch for 0.9.6a or we need to port it
   on 0.9.7 shapshot  first.
  
  
   Cheers,
   Zoran Radenkovic
  
  
  
   ERACOM Products meeting today's security needs.
   Visit our Website at: http://www.eracom.com.au
   Or call ERACOM Pty. Ltd. on: +61 7 5593 4911
  
   __
   OpenSSL Project http://www.openssl.org
   Development Mailing List   [EMAIL PROTECTED]
   Automated List Manager   [EMAIL PROTECTED]
  __
  OpenSSL Project http://www.openssl.org
  Development Mailing List   [EMAIL PROTECTED]
  Automated List Manager   [EMAIL PROTECTED]
 



-- 
Erwann ABALEA
[EMAIL PROTECTED]
RSA PGP Key ID: 0x2D0EABD5
-
Those who can, Do, Those who can't, Criticize.

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

Re: Object names

2000-09-25 Thread Erwann ABALEA


On Mon, 25 Sep 2000, Michael Ströder wrote:

 Jean-Marc Desperrier wrote:
  
  No official central regitry, yes, but at least there is this 
  non-official one :
  http://www.alvestrand.no/objectid/
 
 Thank you. I already knew that one.
 
  It's quite complete, while sure not comprehensive.
 
 The problem is that not the vendors itself add their entries but
 normal users enter what they believe is the name and ASN.1 syntax.
 
 Example: Can someone give me the complete ASN.1 syntax of
 entrustVersInfo (OID 1.2.840.113533.7.65.0)? E.g. alvestrand.no
 says:
 
   entrustVersInfo EXTENSION ::= {
   SYNTAX EntrustVersInfoSyntax
   IDENTIFIED BY { id-nsn-ext 0}
   }
 
   EntrustVersInfoSyntax ::= OCTET STRING
 
 But according to the ASN.1 parser I'm using it seems to be a
 SEQUENCE of a string containing the version (e.g. "V4.0") and a BIT
 STRING containing some flags.
 
 See output of Peter Gutmann's dumpasn1:
 
 : SEQUENCE {
  564 069:   OBJECT IDENTIFIER
 : entrustVersInfo (1 2 840 113533 7 65 0)
  575 04   12:   OCTET STRING, encapsulates {
  577 30   10:   SEQUENCE {
  579 1B4: GeneralString 'V4.0'
  585 032: BIT STRING 4 unused bits
 :   '1001'B
 : }
 :   }
 :   }
 : }
 :   }
 : }

Well alvestrand.no is right on this one You can see it in your
dump... The SEQUENCE is encapsulated in an OCTET STRING...

What you would like is the internal format of this OCTET STRING... Just
ask Entrust...

How could you force anyone to describe the internal format of every
structure they use? Don't even think of it...

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

OpenSSL-0.9.6-beta1 and Linux Redhat 5.1

2000-09-11 Thread Erwann ABALEA



'make' and 'make test' worked perfectly on my machine, a Celeron 400 with
128MB RAM, running RedHat 5.1.

The last few lines of the 'make test' are:

OpenSSL 0.9.6-beta1 11 Sep 2000
built on: Mon Sep 11 18:35:35 CEST 2000
platform: linux-elf
options:  bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) 
blowfish(idx)
compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM
-DMD5_ASM -DRMD160_ASM


-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: OpenSSL

2000-07-11 Thread Erwann ABALEA


There's only one archive for OpenSSL, for all the supported OS.

Download this archive from http://www.openssl.org, just follow the right
links... (hint: search for the word "download")...

On Tue, 11 Jul 2000 [EMAIL PROTECTED] wrote:

 Does anyone know where to download openSSL for windows (if there is)
 
 thanx,
 audrey

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: Pseudo Random Number Generator

2000-03-23 Thread Erwann ABALEA


Does anyone have paid to go through the FIPS-140 evaluation of any part of
OpenSSL? ;-)

On Thu, 23 Mar 2000, David Ahrens wrote:

 Does anyone know if the pseudo random number generator in openssl is 
 FIPS-140 compliant?

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Problem under Win32

2000-03-02 Thread Erwann ABALEA


I compiled OpenSSL-0.9.5 (the latest release) under Win98, with Visual C++
5 and NASM 0.98, as described in the INSTALL.W32 file (as usual).

The compilation was fine, but I tried 'openssl speed dsa', and I don't see
any result after the classic '... First we calculate the appoximate
speed', even after several minutes.

I used to use OpenSSL 0.9.4 without asm, it worked perfectly. I then tried
the same version, with NASM, and it still works perfectly...

When I try to generate a DSA key, it works:
openssl dsaparam -out testdsa.pem 512
openssl dsa testdsa.pem
- I get the key on stdout.

I found another problem with the command line tool openssl, used in it's
"prompt mode"... I'll try to reproduce the behaviour, and I'll post my
results.

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: Adding new cipher suites to TLS with 256+ bit session keys.

2000-02-24 Thread Erwann ABALEA


On Sun, 20 Feb 2000, Eugene Levy wrote:

 Yes I know that even a 1024 bit RSA key and 128 bit symmetric cipher has
 no chance of being broken within the next 20 years.  (Gee, if a 1024 bit
 RSA key could be broken, a lot of us would be issuing our own Versign/
 Thawte certificates with their cracked keys.)  But my boss as asked me

I (and others too) think that 1024 bits RSA will be broken in less than 10
years...

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

RE: [Fwd: OCSP and CSL]

2000-01-26 Thread Erwann ABALEA


On Wed, 26 Jan 2000, Salz, Rich wrote:

 can CRLs be signed by a certificate that is not the CA certificate
 
 No.

What do you mean by "the CA certificate"?

If you take a look at the SET specifications, then the CRLs can be signed
by a different private key and certificate than the ones used to generate
the certificates Basically, you have one certificate to sign the
certificates, and one other to sign the CRLs... A different key pair is
associated with each certificate.

The difference is in the keyUsage extension.

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: How to build ssleay libraries on WindowsNT

2000-01-21 Thread Erwann ABALEA


Please read the file INSTALL.W32, everything's described...

On Mon, 17 Jan 2000, bhushan wrote:

 Could you please explain,how to build static ssleay libraries on
 WindowsNT

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: Benchmark

1999-06-04 Thread Erwann ABALEA


Just run 'openssl speed' and enjoy...

You can also give parameters to the 'openssl speed' command.

On Fri, 4 Jun 1999, Pierre De Boeck wrote:

 Where can I find a program that compute
 benchmark time for the ciphers, digests and
 public key alg of OpenSSL (I use the 0.9.3a version).

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: R: OCSP patching

1999-04-22 Thread Erwann ABALEA


Who wants to write a simple S/MIME tool, able to decrypt, verify, sign,
crypt any mail, so I can use it as a PINE filter? ;-)

On Tue, 20 Apr 1999, Andrea e Luca Giacobazzi wrote:


  [NON-Text Body part not included]


-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: Re(2): Where to get Country list?

1999-04-16 Thread Erwann ABALEA


On Fri, 16 Apr 1999, Jacek Rafal Radzikowski wrote:

 gilbert soueidy wrote:
  If I am not wrong, ISO standards specify 3 characters
  for each country. Are you sure you want a two
  characters codes ?
 Well... You're both right. ISO3166 defines 2, 3 letter and 3 digit
 conutry codes. (Polish codes are PL and 616 AFAIR)

Right... France is 'FR' and '250'... Next! ;-)

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -

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

Re: Question about OIDs

1999-02-12 Thread Erwann ABALEA


On Thu, 11 Feb 1999, Dr Stephen Henson wrote:

 Erwann ABALEA wrote:
  
  I posted this question on the old ssl-users list, but got no answer.
  
  I wanted to add OIDs from SET books, and I'm running into problems.
  
 
 Could you send me a sample certificate that exhibits this behaviour?
 Then I can analyse it and see where the problem lies.

Here they are. You'll find 2 SET root CA certificates, I don't exactly
know which one is really used by the SET world.

I just tried the modifications I just talked about, and I still have the
same result. First of all, the perl script seems to have a bug with
leading 0s, because I have to modify the resulting obj_dat.h, adding a
0x00, a length count on another line, and eventually an offset for the
OIDs defined after this one.

Even with this modification, I still see the OID instead of the
corresponding LN (2.23.42.7.0, instead of "X509v3 SET Hashed Root Key").
 
-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
Telephone: +33 1 34 38 29 50



-BEGIN CERTIFICATE-
MIIGLzCCBRegAwIBAgIBbDANBgkqhkiG9w0BAQUFADAgMQswCQYDVQQGEwJVUzER
MA8GA1UEChMIU0VUIFJvb3QwHhcNOTcwNzE1MDAwMDAwWhcNMDQwNzE1MDAwMDAw
WjAgMQswCQYDVQQGEwJVUzERMA8GA1UEChMIU0VUIFJvb3QwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC7RwokxOIO3MWqAdevLS9kiDoC6G1yLIFrzbrD
QKy/b81HIgs5xYHlwEiPsRn3kJdOIJlmzxsLFhtSj23/a4cZM36mVsNvzZcQnwMe
l4r1XhewOmQDqjnol2GWTUrzN2/oPP+D8+8HDNjNzmB9SRm0muVe4KUKNH9JA8iH
YeufGZeG1nZ8WKbbQ05BLzSRXCQIpQg1XrQ+W/PFXoa31BIaYw1zSKahR7ujFfYK
hXw1kKrpgpYFSH+utO+VEh7GQVq9ycfxLeBm1xttWn4MLtbBu0UPIjkM0GbkS9TH
xhTiYUd/ZBoW82zmBU4orcn7tBRoPafuhkWwtFKzCBhQn8QNAgMBAAGjggNyMIID
bjASBgNVHRMBAf8ECDAGAQH/AgEDMIICyQYDVR0gAQH/BIICvTCCArkwggK1BgRn
KgUAMIICqzCCAqcGBGcqBwYwggKdMIICmRqCApVUaGlzIFNFVCBSb290IENlcnRp
ZmljYXRlIGFuZCBhbnkgY2VydGlmaWNhdGUgYXV0aGVudGljYXRlZCBkaXJlY3Rs
eSBvciBpbmRpcmVjdGx5IGJ5IHRoaXMgY2VydGlmaWNhdGUsIG1heSBvbmx5IGJl
IHVzZWQgdG8gZW5hYmxlICJTZWN1cmUgRmluYW5jaWFsIFRyYW5zYWN0aW9ucyIg
YXMgZGVmaW5lZCBpbiB0aGUgU0VUIFJvb3QgQ2VydGlmaWNhdGUgUHJhY3RpY2Ug
U3RhdGVtZW50IGFuZCwgd2hlbiBhcHByb3ByaWF0ZSwgaW4gYSBTRVQgQnJhbmQg
Q2VydGlmaWNhdGUgUHJhY3RpY2UgU3RhdGVtZW50LiAgTm8gUGFydHkgbWF5IHJl
bHkgdXBvbiB0aGUgU0VUIFJvb3QgQ2VydGlmaWNhdGUgZm9yIGFueSBvdGhlciBw
dXJwb3NlLiAgQSBTRVQgQnJhbmQgc2hhbGwgYmUgYW55IHBheW1lbnQgYnJhbmQg
d2hvc2UgU0VUIGNlcnRpZmljYXRlIGlzIHNpZ25lZCBieSB0aGUgcHJpdmF0ZSBr
ZXkgY29ycmVzcG9uZGluZyB0byB0aGUgcHVibGljIGtleSBjb250YWluZWQgaW4g
dGhpcyBjZXJ0aWZpY2F0ZS4gIEFsbCBtYXR0ZXJzIHJlbGF0aW5nIHRvIHVzYWdl
LCBsaWFiaWxpdHkgYW5kIHByb2NlZHVyZXMgd2l0aCBTRVQgY2VydGlmaWNhdGVz
IGlzc3VlZCBiZW5lYXRoIGEgU0VUIEJyYW5kIHNoYWxsIGJlIGRldGVybWluZWQg
YnkgdGhhdCBTRVQgQnJhbmQuMA4GA1UdDwEB/wQEAwIBBjArBgNVHRAEJDAigA8x
OTk3MDcxNTAwMDAwMFqBDzE5OTgwNzE1MDAwMDAwWjAQBgRnKgcBAQH/BAUDAwcA
gDA8BgRnKgcAAQH/BDEwLzAtAgEAMAkGBSsOAwIaBQAwBwYFZyoDAAAEFOzocvDp
XM5NBtMnGUqm0nD7ZMPmMA0GCSqGSIb3DQEBBQUAA4IBAQC1OngvqhdSgJsum6oe
zr50yvE58mOOlxqir71CU8F4rNbUd1Rzy7ceQ7qayjTHpOvai2lsgA25vHEVnMRd
iqhUJq9TwBYQjL+cgNtmkhlC2LpLv5OAXep5lwSr9/BX8DrfGlih+s9/2027FKGA
Tu40xRMPRAh3HTthdV1hhQjvykba0aN4xtP+cdm0pSIneOHdkNPAyKfTGz67Y69S
heD5Ahm4SG90bpdDd1Xrl6QM7tD/5VTe1sotbqMDdD7jYJY7ESBSMBVxuS2L+R2D
TfLxAvPWzZrVweogoIFAtpeFVR0ZbC/DI89ktLU1qRydh9Gd8kPlYXZPvDAOK+3t
nwHl
-END CERTIFICATE-


-BEGIN CERTIFICATE-
MIIGLzCCBRegAwIBAgIBajANBgkqhkiG9w0BAQUFADAgMQswCQYDVQQGEwJVUzER
MA8GA1UEChMIU0VUIFJvb3QwHhcNOTcwNzE1MDAwMDAwWhcNMDQwNzE1MDAwMDAw
WjAgMQswCQYDVQQGEwJVUzERMA8GA1UEChMIU0VUIFJvb3QwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDU3D664ZT3vs3tIXfP2ohYUQ6P9NoAFB4Np622
llrG0+wl7dhDC25/P54edKAel3Ywym8KY8CjMUAlgLi9KOt9dQtOQTTEIADCy/Sa
IABY2fRAExh3DLUE3re2Q4ukzDZ2ecULF8t+iKEzsNM0J787YdrFIOv5lJqLebKo
jsvB2ZRKmWZQVbKDKH0iPezco+g524NUyYmp31lSn3rvfBFiUuzmZ7o96qtH2+T0
H3PDPex+hH0vKf5sFz91bVZuwE61vyogiuRXrsAuaMkJz4V3Cu86N8tgTEVzf5A+
hh36w/xQirLFijTw8kPuPFa6JOngpYcefDAzd/1d4FcNbBk5AgMBAAGjggNyMIID
bjASBgNVHRMBAf8ECDAGAQH/AgEDMIICyQYDVR0gAQH/BIICvTCCArkwggK1BgRn
KgUAMIICqzCCAqcGBGcqBwYwggKdMIICmRqCApVUaGlzIFNFVCBSb290IENlcnRp
ZmljYXRlIGFuZCBhbnkgY2VydGlmaWNhdGUgYXV0aGVudGljYXRlZCBkaXJlY3Rs
eSBvciBpbmRpcmVjdGx5IGJ5IHRoaXMgY2VydGlmaWNhdGUsIG1heSBvbmx5IGJl
IHVzZWQgdG8gZW5hYmxlICJTZWN1cmUgRmluYW5jaWFsIFRyYW5zYWN0aW9ucyIg
YXMgZGVmaW5lZCBpbiB0aGUgU0VUIFJvb3QgQ2VydGlmaWNhdGUgUHJhY3RpY2Ug
U3RhdGVtZW50IGFuZCwgd2hlbiBhcHByb3ByaWF0ZSwgaW4gYSBTRVQgQnJhbmQg
Q2VydGlmaWNhdGUgUHJhY3RpY2UgU3RhdGVtZW50LiAgTm8gUGFydHkgbWF5IHJl
bHkgdXBvbiB0aGUgU0VUIFJvb3QgQ2VydGlmaWNhdGUgZm9yIGFueSBvdGhlciBw
dXJwb3NlLiAgQSBTRVQgQnJhbmQgc2hhbGwgYmUgYW55IHBheW1lbnQgYnJhbmQg
d2hvc2UgU0VUIGNlcnRpZmljYXRlIGlzIHNpZ25lZCBieSB0aGUgcHJpdmF0ZSBr
ZXkgY29ycmVzcG9uZGluZyB0byB0aGUgcHVibGljIGtleSBjb250YWluZWQgaW4g
dGhpcyBjZXJ0aWZpY2F0ZS4gIEFsbCBtYXR0ZXJzIHJlbGF0aW5nIHRvIHVzYWdl
LCBsaWFiaWxpdHkgYW5kIHByb2NlZHVyZXMgd2l0aCBTRVQgY2VydGlmaWNhdGVz
IGlzc3VlZCBiZW5lYXRoIGEgU0VUIEJyYW5kIHNoYWxsIGJlIGRldGVybWluZWQg
YnkgdGhhdCBTRVQgQnJhbmQuMA4GA1UdDwEB/wQEAwIBBjArBgNVHR

Correction to asn1.h

1999-02-11 Thread Erwann ABALEA


Hi,

I'm new to the list, but I have used SSLeay for 4 or 5 months from now.

I submitted a correction to Eric Young, but it seems it has not been
reported to OpenSSL 0.9.1c:

in asn1.h, line 284, change ocurrence of PRINTABLESTRING_STRING to
PRINTABLESTRING


-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
Telephone: +33 1 34 38 29 50

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

Re: [ssl-users] How to update Trust provider list?

1999-02-03 Thread Erwann ABALEA


On Tue, 2 Feb 1999, Yuriy Stul wrote:

 Hi everybody!
 
 Does anyone know how (programmatically) to update Trust provider list
 for Internet Explorer certificate mechanism?

Just send by HTTP an object to your browser. The object should have the
MIME type: application/x-ca-x509, and the body of this object is a
certificate of a CA to be trusted.

I'm not sure about the MIME type, I write this from memory, but I used
this method, and it works well, both with Netscape and IE4. 

For more info, just read the (poor) documentation contained in SSLeay.

-- 
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
Telephone: +33 1 34 38 29 50
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

98 matches

Mail list logo