Re: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?
At Wed, 22 Oct 2008 21:12:52 -0400 (EDT),
Dean Anderson wrote:
>
> On Wed, 22 Oct 2008, Simon Josefsson wrote:
>
> > Alfred "=?hp-roman8?B?SM5uZXM=?=" <ah at tr-sys.de> writes:
> >
> > > (B) Non-uniqueness of x509_name in Trusted CA Keys TLS extension
> > >
> > > The 3rd-to-last paragraph of Section 6 in the -03 version
> > > of the rfc4366-bis draft states:
> > >
> > > ! Note also that it is possible that a key hash or a Distinguished Name
> > > ! alone may not uniquely identify a certificate issuer (for example, if
> > > ! a particular CA has multiple key pairs). However, here we assume this
> > > ! is the case following the use of Distinguished Names to identify
> > > ! certificate issuers in TLS.
> > >
> > > It seems rather unlikely that this non-uniqueness happens for
> > > a key hash.
> >
> > Can't you have multiple CA certificates for the same key?
>
> You _can_ have multiple key pairs, but knowledge of any key pair allows
> one to calculate P and Q, so having multiple key pairs for the same
> modulus is a "bad idea", because with one pair one can calculate any
> other pair given one of the other pair. I believe that both Schnier's
> Applied Cryptography, 2nd and the CRC Handbook of Applied Cryptography
> recommend against this practice. The CRC Handbook gives the method to
> calculate P and Q given the public and private keys.
The question is whether you can have multiple CA certificates with
*identical* keys, not multiple certificates with the same modulus but
different e/d. The answer to this is "yes". If you want to uniquely
identify a cert you shoul duse a hash of the cert.
-Ekr
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.