Re: openssl req -x509 does not create serial-number 0
On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Patent Infringement Safe Configuration of Openssl
OpenSSL does implement the IDEA algorithm, though, which is still
patented. Thus, it's a very valid question, what the patent status of
each algorithm is, and what the best way to build a noninfringing
version is.
RSA and Diffie-Hellmann are both expired. RC2 and RC4 weren't ever
patented, but RC5 is. (RC4 was being protected as a 'trade secret',
but source that implemented a fully-interoperable cipher was posted to
the 'net. These are the few that I know off the top of my head.)
-Kyle H
On 2/25/06, Vladimir Botka <[EMAIL PROTECTED]> wrote:
> Hi,
> according to E.Rescorla: "SSL and TLS" ISBN 0-201-61598-3 p.53 OpenSSL
> is free for commercial and noncommercial use (BSD-style license). RSA`s
> patent expired in September 2000. As of the direction, I would prefer
> J.Menezes: "Handbook of Applied Cryptography" ISBN 0-8943-8523-7.
>
> Regards,
>
> -vlado
>
> D000
>
>
> On Fri, 24 Feb 2006, Kyle Hamilton wrote:
>
> > I would direct you to Schneier ("Applied Cryptography") for patents
> > related to things that were known in 1996, including elliptic curve.
> >
> > None of us on the list are lawyers, and we certainly haven't done an
> > exhaustive patent search.
> >
> > -Kyle H
> >
> > On 2/20/06, Roger Boden <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> >> I am currently looking into what configuration of openssl that would be
> >> patent infringement safe world wide. This is what come up with so far.
> >>
> >> IDEA should be left out, Ascom holds a patent for this algorithm.
> >> RC5 should be left out. RSA security holds a patent for this algorithm
> >>
> >> MD2, MD4 and MD5 are ok to use. RSA Security has published an IPR
> >> disclosure
> >> on www.ietf.org stating that these algorithms can be made, used and sold
> >> without any license from RSA Security Inc.
> >>
> >> Is RSA ok to include? The RSA patent has expired in the US, but what about
> >> other countries?
> >>
> >> What about eliptic curves? I have found some discussions on emailing lists
> >> about Sun's eliptic curve contribution to Openssl and possible IPR issues?
> >> What is the status?
> >>
> >> Are there other patents or other IPR issues that needs to be considered?
> >>
> >> Regards Roger
> >>
> >> _
> >> Nyhet! Hotmail direkt i Mobilen! http://mobile.msn.com/
> >>
> >> __
> >> OpenSSL Project http://www.openssl.org
> >> User Support Mailing Listopenssl-users@openssl.org
> >> Automated List Manager [EMAIL PROTECTED]
> >>
> > __
> > OpenSSL Project http://www.openssl.org
> > User Support Mailing Listopenssl-users@openssl.org
> > Automated List Manager [EMAIL PROTECTED]
> >
> >
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
On Sun, Feb 26, 2006, Kyle Hamilton wrote: > On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl req -x509 does not create serial-number 0
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 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 req -x509 does not create serial-number 0
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 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: AES documentation?
On 2/25/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: The preferred interface to all ciphers is EVP. The reason I am not using the EVP interface was to save space. Currently OpenSSL is already making my end product way too large so I'm trying to minimize the code dependancies. 128 bits is fixed by for AES. I assume you mean the AES implementation strictly follows FIPS-197 because Rijndael itself certainly allows for varying the block size. Thanks
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]
calling SSL_library_init multiple times
Hi, Can I call SSL_library_init multiple times in my code under different threads? From the documented return values, I conclude that it should be possible. Can some one confirm it? Thanks JB
build non-bsafe version of Openssl
Hi ,I am trying to build a non-bsafe version of Openssl. Could anyone just tell me the exact steps I need to follow to do so? From what I understand, Bsafe is now part of Openssl. Which option would help me build Openssl which does not use the Bsafe libraries? Any help is appreciated. Thanks in advance,Smitha
