Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that part of the difficulty here is the words used. Our experience in other areas is overwhelmingly in favor of serial number being a sample from a counter that starts at 0 or 1 and is incremented by 1 every time it's consulted. So we see a field described as a serial number and ask why it isn't behaving properly. It's too bad the standard calls this attribute a serial number rather than, say, certificate unique identifier, but the term is fixed now. - -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Open-source executable: $0.00. Source: $0.00 Control: priceless! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFEBFyts/NR4JuTKG8RAvwvAJkBaF0r/EWrlN94kzBXyhdYDukKLQCfVOIr P337Skc1EMAy4i1wowAXiDQ= =nhvt -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour,
Hodie pr. Kal. Mar. MMVI est, Mark H. Wood scripsit:
I think that part of the difficulty here is the words used. Our
experience in other areas is overwhelmingly in favor of serial number
being a sample from a counter that starts at 0 or 1 and is incremented by
1 every time it's consulted.
That's not really incompatible with something random, from the
outside. Just keep an internal counter, pack it properly into a
128bit structure, encrypt it with an AES key, et voilà, you have a
random serial number, and you're sure you won't have any duplicate.
A command-line version (for the CA.{pl,sh} utility) could be this
script:
- genserial.sh
#! /bin/sh
COUNTER=`cat counter`
echo -n $COUNTER | openssl enc -K `od -t x1 -A n aeskey.bin | sed 's/ //g'`
-aes-128-ecb -iv | od -t x1 -A n | sed 's/ //g' serial
echo obase=16; ibase=16; $COUNTER+1 | bc counter
-
For this to work, you have to generate a random AES key:
dd if=/dev/urandom of=aeskey.bin bs=1 count=16
and initialize your counter file:
echo 1 counter (or any value you want)
Call this script to generate a serial number based on the counter, and
increment the counter for the next one. Just tell 'openssl ca' to use
the generated serial, as what is done by default by CA.{pl,sh}.
The iv parameter value is not important, because we use the ECB mode,
but the software needs one to be set, so just make it happy.
This simple script doesn't allow you to generate 2^128 different
serial numbers, you'll only get 16^16 different ones, but for a
home-made CA, that should be enough.
So we see a field described as a serial
number and ask why it isn't behaving properly. It's too bad the standard
calls this attribute a serial number rather than, say, certificate
unique identifier, but the term is fixed now.
The standard goes back to 1988 for the final X.509 v1, and at that
time, the described X.509 collision attack didn't exist.
Then, somewhere between 1988 and 1997, X.509v2 came in, adding the
subjectUniqueIdentifier field (a UniqueIdentifier is a BIT STRING),
which was replaced in 1997 (X.509v3) by the subjectKeyIdentifier
extension.
The subjectUniqueIdentifier and subjectKeyIdentifier are really meant
to be unique by themselves (wether it's truely unique or not is left
to the implementor), but the serialNumber is not unique alone, by
definition.
--
Erwann ABALEA [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour, Hodie IV Kal. Mar. MMVI est, Kyle Hamilton scripsit: [...] Can you give me a pointer to the several standards that reflect and enforce the issuer name + serial number uniqueness? A more The X.509 says it all. From this standard, a CA is a name (not a key, really a name). That allows you to renew the CA's key (and certificate), and this key+certificate still belongs to the same CA. Whence, you can revoke an issued certificate that was signed by an anterior CA key. This (issuer name, serial number) uniqueness is clearly stated in chapter 7 (Public-keys and public-key certificates): serialNumber is an integer assigned by the CA to each certificate. The value of serialNumber must be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). -- Erwann ABALEA [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
Bonjour, Hodie IV Kal. Mar. MMVI est, Dr. Stephen Henson scripsit: [... about serial numbers ...] Some CAs choose consecutive values, other what look like random values of hashes. One commercial reason for not using consecutive values is that competitors can work out how many certificates you've issued... One good technical reason to choose random serial numbers was demonstrated by the a paper written by Lenstra, Wang, and Weger (http://eprint.iacr.org/2005/067). The point here is that if the attacker can predict the content of a certificate, he can carefully generate a public key so that the signature of a certificate can be used on another certificate with another identity and public key. This attack is based on flaws on MD5 demonstrated in summer 2004. SHA1 is now under attack, and until the SHA2 series is well understood by a large proportion of the installed software base, CAs are forced to use SHA1... See also: http://www.win.tue.nl/~bdeweger/CollidingCertificates/ The CA has the possibility to change the name of the issued certificate, by adding a random element (a kind of serial number), but this isn't usually well percieved (the customer always asks for clarification about this random stuff added to his identity), and it prevents an end-user to renew a certificate with the same exact identity (since this will render the counter-measure useless). The only logical, non disturbing, embedded place for some random data is the serial number. Several ways exists to make it random from the outside, and still make sure each serial number is unique among a CA. -- Erwann ABALEA [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Erwann ABALEA wrote: Bonjour, Hodie IV Kal. Mar. MMVI est, Dr. Stephen Henson scripsit: [... about serial numbers ...] Some CAs choose consecutive values, other what look like random values of hashes. One commercial reason for not using consecutive values is that competitors can work out how many certificates you've issued... One good technical reason to choose random serial numbers was demonstrated by the a paper written by Lenstra, Wang, and Weger (http://eprint.iacr.org/2005/067). The point here is that if the attacker can predict the content of a certificate, he can carefully generate a public key so that the signature of a certificate can be used on another certificate with another identity and public key. This attack is based on flaws on MD5 demonstrated in summer 2004. SHA1 is now under attack, and until the SHA2 series is well understood by a large proportion of the installed software base, CAs are forced to use SHA1... See also: http://www.win.tue.nl/~bdeweger/CollidingCertificates/ Just to add that that version of the attack can only generate colliding certificates which are identical other than the public keys. The CA has the possibility to change the name of the issued certificate, by adding a random element (a kind of serial number), but this isn't usually well percieved (the customer always asks for clarification about this random stuff added to his identity), and it prevents an end-user to renew a certificate with the same exact identity (since this will render the counter-measure useless). From my understanding of the collision a non-critical extension would be another place but people would of course ask what it was for. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Dr. Stephen Henson wrote: On Sun, Feb 26, 2006, Erwann ABALEA wrote: The CA has the possibility to change the name of the issued certificate, by adding a random element (a kind of serial number), but this isn't usually well percieved (the customer always asks for clarification about this random stuff added to his identity), and it prevents an end-user to renew a certificate with the same exact identity (since this will render the counter-measure useless). From my understanding of the collision a non-critical extension would be another place but people would of course ask what it was for. My recollection of the collision construction was faulty. Non critical extensions wouldn't do because they would appear after the public key. The construction only needs to be able to predict everything before the public key portion of a certificate: it can use whatever the CA provides afterwards as long as it is the same in the two certificates. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
