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 completely lost?
/Olle
On Mar 4, 2005, at 13:44, Joerg Schneider wrote:
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 paper I understand that this results in two certificates,
which
are identical except for the public key and that the attacker knows the
private keys for both.
Do you think it would be possible to modify the attack, to get
different
Subject DNs or SubjectAltNames under the control of the attacker? This
would scare me more.
On a different note:
In a real life scenario a CA would accept PKCS#10 requests, create the
TBS
using parts of the requests, providing other parts like
notBefore/notAfter
and the serialNumber, and finally sign the result. This would make the
attack more difficult, as the attacker would have to guess, what the CA
makes out of the request, including time of issuance and serialNumber.
Do you think choosing the serialNumber in a way that it cannot be
guessed
by the attacker would be an effective way to counter collsion based
attacks on CAs?
Best regards,
J�rg
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
