openssl req -x509 does not create serial-number 0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

openssl req -x509 does not create serial-number 0

Georg Lohrer-6
Hi,

if I use the command:

$ /usr/local/bin/openssl req -x509 -new -days 30 -key ./cacert.key -out ./cacert.pem -outform PEM

to create a self-signed root-certificate the 'man req' page says:

  -x509 this option outputs a self signed certificate instead of a
        certificate request. This is typically used to generate a
        test certificate or a self signed root CA. The extensions
        added to the certificate (if any) are specified in the
        configuration file. Unless specified using the
        set_serial option 0 will be used for the serial
        number.

So I expected a serial-number of 0, but get a:

$ /usr/local/bin/openssl x509 -serial -noout -in cacert.pem
serial=806E141592B2EFF9

If I use the '-set_serial' I will get the expected serial number of course.
The automatically used /usr/local/ssl/openssl.cnf does only these serial
related lines:


####################################################################
[ ca ]
default_ca      = CA_default            # The default ca section

####################################################################
[ CA_default ]

dir             = ./demoCA              # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same
# subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number


Even if I create an explicit serial-file it won't be used for the 'req'
command (tested with strace).

Any ideas what I'm doing wrong? Or is the man-page wrong?

Ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
On Sun, Feb 26, 2006, Georg Lohrer wrote:

>
> Even if I create an explicit serial-file it won't be used for the 'req'
> command (tested with strace).
>
> Any ideas what I'm doing wrong? Or is the man-page wrong?
>

The manual page needs updating. It now uses a random serial number unless a
serial number is given explicitly. This was to reduce the chance of duplicate
issuer names and serial numbers.

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Kyle Hamilton
Is there a way to specify the old behavior?  (I'm collecting as much
information as I can on current practice and putting it all together
-- the overloading of 'authorityKeyIdentifier' is only part of the
problem with current X.509 practice, and that overloading creates a
situation where software makers introduce incompatible changes -- I've
got logging software and log processing software that relies on the
former, serial functionality.)

-Kyle H

On 2/25/06, Dr. Stephen Henson <[hidden email]> wrote:

> On Sun, Feb 26, 2006, Georg Lohrer wrote:
>
> >
> > Even if I create an explicit serial-file it won't be used for the 'req'
> > command (tested with strace).
> >
> > Any ideas what I'm doing wrong? Or is the man-page wrong?
> >
>
> The manual page needs updating. It now uses a random serial number unless a
> serial number is given explicitly. This was to reduce the chance of duplicate
> issuer names and serial numbers.
>
> 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 List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
On Sat, Feb 25, 2006, Kyle Hamilton wrote:

> Is there a way to specify the old behavior?  (I'm collecting as much
> information as I can on current practice and putting it all together
> -- the overloading of 'authorityKeyIdentifier' is only part of the
> problem with current X.509 practice, and that overloading creates a
> situation where software makers introduce incompatible changes -- I've
> got logging software and log processing software that relies on the
> former, serial functionality.)
>

It was introduced as a bug fix to stop OpenSSL producing invalid certificates
under certain circumstances.

A clarification indicated that zero was considered an invalid serial number.

Issuing certificates with duplicate issuer and serial numbers is illegal and
can cause strange problems which are difficult to diagnose.

If you want to keep the previous behaviour when you use "openssl req -x509" you
have to explicitly use the -set_serial option.

The other case is where a serial number file is created. To keep the old
behaviour you need to explicitly create a serial number file with the
appropriate value.

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Kyle Hamilton
On 2/25/06, Dr. Stephen Henson <[hidden email]> wrote:
> It was introduced as a bug fix to stop OpenSSL producing invalid certificates
> under certain circumstances.
>
> A clarification indicated that zero was considered an invalid serial number.

"serialNumber: A unique positive integer."  At least I think.

> Issuing certificates with duplicate issuer and serial numbers is illegal and
> can cause strange problems which are difficult to diagnose.

let's see... you're talking about the authorityKeyIdentifier?  I
thought that that went up 2 steps up the tree and then gave a serial
number of cert issued by that CA.

And I'm trying to parse this more effectively, can you tell me if you
meant something other than: "A CA that issues certificates cannot
issue a certificate that has the same serial number as its own serial
number"?  This suggests that the CA's serial number is imported into
the context of its own signatures' serial numbers, even when it's a
sub-CA?

> If you want to keep the previous behaviour when you use "openssl req -x509" you
> have to explicitly use the -set_serial option.

Thank you for the workaround.

> The other case is where a serial number file is created. To keep the old
> behaviour you need to explicitly create a serial number file with the
> appropriate value.

...or just use the one I already have, I would presume?

Thanks for your help, Dr. Henson.

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Georg Lohrer-6
In reply to this post by Dr. Stephen Henson
On So, 26 Feb 2006, Dr. Stephen Henson wrote:

> On Sun, Feb 26, 2006, Georg Lohrer wrote:
>
> >
> > Even if I create an explicit serial-file it won't be used for the 'req'
> > command (tested with strace).
> >
> > Any ideas what I'm doing wrong? Or is the man-page wrong?
> >
>
> The manual page needs updating. It now uses a random serial number unless a
> serial number is given explicitly. This was to reduce the chance of duplicate
> issuer names and serial numbers.

Ah yes; I scrutinized through the code and saw that the current time will be
used for forming the random number (crypto/bn/bn_rand.c).

As I have hopefully understood setting the serial number of a CA to a
distinct number like 1 is good practice. From a technical point of view any
number should as good as another as long as they are unique (as you mentioned
in your post to Kyle). But for a CA? I saw a CA-certificate from Thawte having
a serial number of 1 and a CA-certificate of VeriSign having a perhaps random
number. What will be the best way for a CA? Is there any preferred way?

Ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
In reply to this post by Kyle Hamilton
On Sat, Feb 25, 2006, Kyle Hamilton wrote:

> On 2/25/06, Dr. Stephen Henson <[hidden email]> wrote:
> > It was introduced as a bug fix to stop OpenSSL producing invalid certificates
> > under certain circumstances.
> >
> > A clarification indicated that zero was considered an invalid serial number.
>
> "serialNumber: A unique positive integer."  At least I think.
>

The type of serialNumber that should be accepted doesn't place any limits on
the sign.

RFC3280 places restrictions on what a CA should generate.  It says it must be
"non-negative" at one point which is >= 0. In another place it states that zero
or negative in invalid i.e. >0 is valid.

> > Issuing certificates with duplicate issuer and serial numbers is illegal and
> > can cause strange problems which are difficult to diagnose.
>
> let's see... you're talking about the authorityKeyIdentifier?  I
> thought that that went up 2 steps up the tree and then gave a serial
> number of cert issued by that CA.
>
> And I'm trying to parse this more effectively, can you tell me if you
> meant something other than: "A CA that issues certificates cannot
> issue a certificate that has the same serial number as its own serial
> number"?  This suggests that the CA's serial number is imported into
> the context of its own signatures' serial numbers, even when it's a
> sub-CA?
>

It is the combination of issuer name + serial number which must be unique in
general: that's enforced by several standards.

Certain pieces of software assumes that issuer name + serial number can be
used as a unique index and can cause all manner of problems if that turns out
not to be the case.

An obvious consequence is that a CA cannot sign different certificates with
the same serial number.

Whether a CA can sign a certificate with its own serial number depends on the
CA.

If the CA has the same issuer name and subject name then it has
effectively "issued itself" (the term "self issued" is sometimes used) so it
cannot sign a further certificate with its serial number.

In the case of CAs with different issuer and subject names that isn't the case
and it can issue a certificate with its own serial number.

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Richard Salz
In reply to this post by Kyle Hamilton
> let's see... you're talking about the authorityKeyIdentifier?  I
> thought that that went up 2 steps up the tree and then gave a serial
> number of cert issued by that CA.

No, it identifies the key that is signing the actual cert (or CRL). A CA's
subject key identifier (SKI) gets populated as the AKI into everything it
signs.

        /r$

--
SOA Appliance Group
IBM Application Integration Middleware


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Kyle Hamilton
In reply to this post by Dr. Stephen Henson
On 2/25/06, Dr. Stephen Henson <[hidden email]> wrote:

> On Sat, Feb 25, 2006, Kyle Hamilton wrote:
>
> > "serialNumber: A unique positive integer."  At least I think.
> >
>
> The type of serialNumber that should be accepted doesn't place any limits on
> the sign.
>
> RFC3280 places restrictions on what a CA should generate.  It says it must be
> "non-negative" at one point which is >= 0. In another place it states that zero
> or negative in invalid i.e. >0 is valid.

ooh.  Opportunity for errata.

>
> > > Issuing certificates with duplicate issuer and serial numbers is illegal and
> > > can cause strange problems which are difficult to diagnose.
> >
> > let's see... you're talking about the authorityKeyIdentifier?  I
> > thought that that went up 2 steps up the tree and then gave a serial
> > number of cert issued by that CA.
> >
> > And I'm trying to parse this more effectively, can you tell me if you
> > meant something other than: "A CA that issues certificates cannot
> > issue a certificate that has the same serial number as its own serial
> > number"?  This suggests that the CA's serial number is imported into
> > the context of its own signatures' serial numbers, even when it's a
> > sub-CA?
> >
>
> It is the combination of issuer name + serial number which must be unique in
> general: that's enforced by several standards.
>
> Certain pieces of software assumes that issuer name + serial number can be
> used as a unique index and can cause all manner of problems if that turns out
> not to be the case.

This raises the potential for a Denial of Service capability enforced
by the standards.  (In fact, NSS got hit by this DoS issue several
years back, when an untrusted certificate with the same
IssuerName+SerialNumber was put in the certificate store without any
trust, and was used to verify certificates signed with that AKI... the
net effect being that certs signed by the trusted issuer couldn't be
verified.)

> An obvious consequence is that a CA cannot sign different certificates with
> the same serial number.
>
> Whether a CA can sign a certificate with its own serial number depends on the
> CA.
>
> If the CA has the same issuer name and subject name then it has
> effectively "issued itself" (the term "self issued" is sometimes used) so it
> cannot sign a further certificate with its serial number.
>
> In the case of CAs with different issuer and subject names that isn't the case
> and it can issue a certificate with its own serial number.
>
> Steve.

Can you give me a pointer to the several standards that reflect and
enforce the issuer name + serial number uniqueness?  A more
appropriate way of handling it would be issuer name + hash of pubkey +
serial number -- even though this might screw up other parts of the
authentication/verification protocol (esp. in the case of a CA rekey),
it also allows for completely dead CA structures to not interfere with
live ones.

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
On Sun, Feb 26, 2006, Kyle Hamilton wrote:

> On 2/25/06, Dr. Stephen Henson <[hidden email]> wrote:
>
> >
> > It is the combination of issuer name + serial number which must be unique in
> > general: that's enforced by several standards.
> >
> > Certain pieces of software assumes that issuer name + serial number can be
> > used as a unique index and can cause all manner of problems if that turns out
> > not to be the case.
>
> This raises the potential for a Denial of Service capability enforced
> by the standards.  (In fact, NSS got hit by this DoS issue several
> years back, when an untrusted certificate with the same
> IssuerName+SerialNumber was put in the certificate store without any
> trust, and was used to verify certificates signed with that AKI... the
> net effect being that certs signed by the trusted issuer couldn't be
> verified.)
>

Yes implementations have to be careful they don't make assumptions about
untrusted certificates which may deliberately break the rules.

> > An obvious consequence is that a CA cannot sign different certificates with
> > the same serial number.
> >
> > Whether a CA can sign a certificate with its own serial number depends on the
> > CA.
> >
> > If the CA has the same issuer name and subject name then it has
> > effectively "issued itself" (the term "self issued" is sometimes used) so it
> > cannot sign a further certificate with its serial number.
> >
> > In the case of CAs with different issuer and subject names that isn't the case
> > and it can issue a certificate with its own serial number.
> >
> > Steve.
>
> Can you give me a pointer to the several standards that reflect and
> enforce the issuer name + serial number uniqueness?
>

If you look for the "serialNumber" definition in many certificate texts it is
either mentioned or implied. It is one of those things that is considered so
fundamental it is often taken for granted.

The uniqueness for a single CA is explicitly stated by 4.1.2.2 in RFC3280.

There are several cases where it is implied by virtue of the fact that a
certificate identifier is issuer name and serial number. If that was
ambiguous certain protocols wouldn't work.

CRLs are one example.

AKID is another.

S/MIME is another. The signer certificate(s) for signedData and the
recipient certificate(s) for enveloped data are identified by issuer name and
serial number.

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
In reply to this post by Georg Lohrer-6
On Sun, Feb 26, 2006, Georg Lohrer wrote:

>
> As I have hopefully understood setting the serial number of a CA to a
> distinct number like 1 is good practice. From a technical point of view any
> number should as good as another as long as they are unique (as you mentioned
> in your post to Kyle). But for a CA? I saw a CA-certificate from Thawte having
> a serial number of 1 and a CA-certificate of VeriSign having a perhaps random
> number. What will be the best way for a CA? Is there any preferred way?
>

The problem with OpenSSL by default using '1' and then consecutive numbers was
that newboes were following some rather ancient "cookbooks" which came
with certain projects using OpenSSL and ended up producing loads of
duplicates. Even using the recommended methods (CA.pl) that was still
possible.

To give you a simple example. As a test case someone might use the default
values for a certificate in the fields and put something like "test" in the
fields without a default. They might install that certificate or install it on
a radnsom colllection of machines. If they then get it wrong and try again
later with the same values, which would be a duplicate serial number in the
two CAs for a start.

If the two CAs had issued end user certificates you'd get the situation where
apparently bizarre errors such as certificate signature failures would occur:
because the other CA public key was used to verify the signatures on
certificates.

The fairly large random value for serial numbers is designed to avoid that
situation but still allow the more knowledgeable user to override that.

If you are sure the issuer name and serial number will be unique then you can
choose any value you wish.

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...

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Erwann ABALEA
In reply to this post by Kyle Hamilton
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 <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: openssl req -x509 does not create serial-number 0

Georg Lohrer-6
In reply to this post by Dr. Stephen Henson
On So, 26 Feb 2006, Dr. Stephen Henson wrote:

[example snipped]

> The fairly large random value for serial numbers is designed to avoid that
> situation but still allow the more knowledgeable user to override that.
>
> If you are sure the issuer name and serial number will be unique then you can
> choose any value you wish.

Fine, that's understandable.

> One commercial reason for not using consecutive values is that competitors can
> work out how many certificates you've issued...

Yeah, the same procedure as with consecutive invoice-numbers indicating the
number of clients ;-)

Ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Erwann ABALEA
In reply to this post by Dr. Stephen Henson
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 <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Dr. Stephen Henson
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Mark H. Wood
In reply to this post by Erwann ABALEA
-----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   [hidden email]
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Re: openssl req -x509 does not create serial-number 0

Erwann ABALEA
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 ffff | 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 <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]