Hi all,
We announce the construction of two different valid X.509 certificates
that have identical signatures. This is based on MD5 collisions.
One could e.g. construct the to-be-signed parts of the certificates,
and get the one certificate signed by a CA. Then a valid signature for
the other ce
Benne,
> One could e.g. construct the to-be-signed parts of the certificates,
> and get the one certificate signed by a CA. Then a valid signature for
> the other certificate is obtained, while the CA has not seen proof of
> possession of the private key of this second certificate.
>From the pape
Seems to me that a CA can nullify this attack by choosing a serial
number or RDN component (after all, a CA should vet the DN and not
simply sign what's in the PKCS#10 request), such that the public key
does not end up at an "appropriate" DER-encoded offset in the
certificate. Or am I completel
Olle Mulmo wrote:
> Seems to me that a CA can nullify this attack by choosing a serial
number or RDN component (after all, a CA should vet the DN and not
simply sign what's in the PKCS#10 request), such that the public key
does not end up at an "appropriate" DER-encoded offset in the
> certifica
[EMAIL PROTECTED]
> Sent: vrijdag 11 maart 2005 11:52
> To: Olle Mulmo
> Cc: Weger, B.M.M. de; cryptography@metzdowd.com
> Subject: Re: Colliding X.509 Certificates
>
> Olle Mulmo wrote:
> > Seems to me that a CA can nullify this attack by choosing a serial
> number or
Hi Joerg,
> My concern is not MD5, its SHA-1. I don't see that we can get rid of
> SHA-1 in certificates in the next 5 years:
> * None of the alternatives is widely implemented today.
> * For controlled environments like in-house applications you might be
> able to switch earlier (0-2 years).
>
