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

2010-08-09 Thread David Shambroom

RFC 5280 is just what it says it is:

Internet X.509 Public Key Infrastructure Certificate and Certificate 
Revocation List (CRL) Profile


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.


Erwann ABALEA wrote:

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.


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


Re: openssl-1.0.0a and glibc detected sthg ;)

2010-08-09 Thread Mounir IDRASSI

 Hi,

Signature verification is done through a modular exponentiation (using 
public exponent and modulus) that always leads to a result even fur a 
bogus RSA modulus.
This result is checked against the PKCS#1 padding format. Since the RSA 
private key is invalid, the output of this exponentiation is different 
from DataToBeSigned used during certificate creation and thus the code 
doesn't find the PKCS#1 padding block header.

So, the signature is bad because the decrypted signature has a bad format!
I hope this clarifies things to you.

You say at the end of your message that the private key was generated by 
a python wrapper, certainly a wrapper of OpenSSL, but in a previous 
message you are saying that you generated the key yourself (pen and 
paper). Which statement is correct? Maybe your wrapper wraps something 
else...


Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr



On 8/9/2010 7:44 AM, Georgi Guninski wrote:

is the certificate at http://marc.info/?l=openssl-devm=128118163216952w=2
(with the malformed key) *syntactically* correct modulo the bad self signature?

with 1.0.0a
~/local/bin/openssl verify -check_ss_sig -CAfile /tmp/CA-P.cert /tmp/CA-P.cert


/tmp/CA-P.cert: CN = CA
error 7 at 0 depth lookup:certificate signature failure
139828504536744:error:0407006A:rsa 
routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
139828504536744:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding 
check failed:rsa_eay.c:699:
139828504536744:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP 
lib:a_verify.c:184:

echo $?
0

i would expect an error about bad self signature, not format stuff.

the private key was generated by a python wrapper, the cert was generated with
ubuntu's 0.9.8k 25 Mar 2009


On Sun, Aug 08, 2010 at 03:21:34PM +0200, Mounir IDRASSI wrote:
__
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] 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-1.0.0a and glibc detected sthg ;)

2010-08-09 Thread Georgi Guninski
hi,


On Mon, Aug 09, 2010 at 10:36:03AM +0200, Mounir IDRASSI wrote:
  Hi,
 
 Signature verification is done through a modular exponentiation
 (using public exponent and modulus) that always leads to a result
 even fur a bogus RSA modulus.
 This result is checked against the PKCS#1 padding format. Since the
 RSA private key is invalid, the output of this exponentiation is
 different from DataToBeSigned used during certificate creation and
 thus the code doesn't find the PKCS#1 padding block header.
 So, the signature is bad because the decrypted signature has a bad format!
 I hope this clarifies things to you.


ok. i expected a message bad number instead of bad signature format


 You say at the end of your message that the private key was
 generated by a python wrapper, certainly a wrapper of OpenSSL, but
 in a previous message you are saying that you generated the key
 yourself (pen and paper). Which statement is correct? Maybe your
 wrapper wraps something else...
 

lol. the pen/paper generation was just humour.

this key was generated with pycrypto + some other pure python code for export to
your format. (the small prime was included on purpose).

i don't know if pycrypto depends on openssl (though it is not a
 direct wrapper).

the cert was generated entirely by openssl.


the imports:

from Crypto.PublicKey import RSA
from Crypto.Util.number import inverse
import random
import sys
from Crypto.PublicKey import pubkey
from Crypto.Util import number
import crypto # utils
import Crypto
from fractions import gcd
from Crypto.Hash import MD5


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


Re: [openssl.org #2315] PSS certificates with keysize n*8+1 don't validate

2010-08-09 Thread Martin Kaiser via RT
Hi Hanno, all,

Thus wrote Hanno Boeck via RT (r...@openssl.org):

 openssl genrsa 2001   test.key

 openssl req -batch -new -x509 -sigopt rsa_padding_mode:pss -nodes -days 9 
 -key test.key  test.crt

 openssl verify -check_ss_sig -CAfile test.crt test.crt

I've had a quick look, the problem is that the saltlen encoded in the
certificate (==229) and the saltlen used for the calculations (==228)
are different. In RSA_padding_add_PKCS1_PSS_mgf1(), RSA_size(rsa) is
250. In rsa_item_sign(), EVP_PKEY_size(pk) is 251.

I can't take the ticket in the RT but I'm happy to progress this and
propose a patch.

Best regards,

   Martin


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


[openssl.org #2316] Build issue on Tru64 (Dl_info must specify a type)

2010-08-09 Thread Cameron Hague via RT
Hello there,

After running ./config on my Alpha Tru64 server and then running make, lots
gets made until finally it breaks with the following error.

cc: Error: dso_dlfcn.c, line 445: In this declaration, Dl_info must
specify a type. (badparsedecl)
Dl_info dli;
^
cc: Error: dso_dlfcn.c, line 455: In this statement, dli is not declared.
(undeclared)
if (dladdr(addr,dli))
-^

Is there a package I'm missing or a configuration switch of the ./config
script that I need?
I've looked elsewhere but cannot work out what this problem is.

Your help would be greatly appreciated.

Cameron

-- 

*Cameron Hague*

Senior Developer

*Invar Limited*

University Way

Cranfield Technology Park

Cranfield

Bedfordshire

MK43 0EQ

United Kingdom



Office Telephone: +44 (0) 1234 436 000

Direct Telephone: +44 (0) 1234 436 013

Mobile: +44 (0) 7584 236 607

Office Fax:+44 (0) 1234 436 001



Registered in England no: 05084073, VAT no: GB 859 6330 87

*enquir...@invarsystems.co enquir...@invar.co.ukm*

* *

Disclaimer

This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent
those of Invar Limited.

If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to
anyone.

Please contact the sender if you believe you have received this email in
error.

Hello there,After running ./config on my Alpha Tru64 server and then running make, lots gets made until finally it breaks with the following error.cc: Error: dso_dlfcn.c, line 445: In this declaration, Dl_info must specify a type. (badparsedecl)
        Dl_info dli;^cc: Error: dso_dlfcn.c, line 455: In this statement, dli is not declared. (undeclared)        if (dladdr(addr,dli))-^
Is there a package Im missing or a configuration switch of the ./config script that I need?Ive looked elsewhere but cannot work out what this problem is.Your help would be greatly appreciated.
Cameron-- Cameron Hague

Senior Developer

Invar Limited

University Way

Cranfield Technology Park

Cranfield

Bedfordshire

MK43 0EQ

United Kingdom

 

Office Telephone: +44 (0) 1234 436 000

Direct Telephone: +44 (0) 1234 436 013

Mobile: +44 (0) 7584 236 607

Office Fax:+44 (0) 1234 436 001

 

Registered in England no: 05084073, VAT no: GB 859 6330
87

enquir...@invarsystems.com

 

Disclaimer

This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Invar Limited.

If you are not the intended recipient of this email and its attachments,
you must take no action based upon them, nor must you copy or show them to
anyone.

Please contact the sender if you believe you have received this email in
error.


Re: [openssl.org #2316] Build issue on Tru64 (Dl_info must specify a type)

2010-08-09 Thread Steven M. Schweda
From: Cameron Hague via RT r...@openssl.org

 After running ./config on my Alpha Tru64 server

   my Alpha Tru64 server is not a very useful description of anything.

  and then running make, lo=
 ts
 gets made until finally it breaks with the following error.
 
 cc: Error: dso_dlfcn.c, line 445: In this declaration, Dl_info must
 specify a type. (badparsedecl)
 Dl_info dli;
 ^
 cc: Error: dso_dlfcn.c, line 455: In this statement, dli is not declare=
 d.
 (undeclared)
 if (dladdr(addr,dli))
 -^

   The actual compiler command with its results would be more
informative than only its results.

 Is there a package I'm missing or a configuration switch of the ./config
 script that I need?

   It's hard to say what you might need, because I don't really know
what you did where, how, or what happened when you did it.

 I've looked elsewhere but cannot work out what this problem is.

   And with approximately no useful information, I probably can't,
either.  Around here:

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009

urtx# cc -V
Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver

urtx# CC=cc ./config
[...]

urtx# gmake
[...]
making all in crypto/dso...
gmake[2]: Entering directory `/usr/local/src/openssl/openssl-1.0.0a/crypto/dso'
cc -I.. -I../.. -I../asn1 -I../evp -I../../include  -DOPENSSL_THREADS
-pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast
-readonly_strings -DOPENSSL_BN_ASM_MONT   -c -o dso_dl.o dso_dl.c
cc -I.. -I../.. -I../asn1 -I../evp -I../../include  -DOPENSSL_THREADS
-pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast
-readonly_strings -DOPENSSL_BN_ASM_MONT   -c -o dso_dlfcn.o dso_dlfcn.c
cc -I.. -I../.. -I../asn1 -I../evp -I../../include  -DOPENSSL_THREADS
-pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast
-readonly_strings -DOPENSSL_BN_ASM_MONT   -c -o dso_err.o dso_err.c
[...]

   My /usr/include/dlfcn.h typedefs Dl_info if the right macros are
defined (or not), which seems to be true (-DDSO_DLFCN -DHAVE_DLFCN_H). 
See crypto/dso/dso_dlfcn.c.  Look for dlfcn.h.


   The big problem I had on this system was getting
crypto/alphacpuid.s into position (and keeping it there after make
clean).



   Steven M. Schweda   s...@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org