RE: [saag] X.509 certificate collision, via MD5 collisions

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Denis,

Thanks.  When 3126 is used, there is additional basis for NR.  That is good.

Thinking ahead for SHA-1 (assuming it has similar vulnerability), I wonder
if 3126 should be revised to use a different hashing algorithm than the one
used to sign the certificate to shore up the NR argument.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Denis Pinkas
Sent: Monday, March 07, 2005 9:50 AM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions



Santosh,

> Denis,

> But, that alone will not support NR in case of the Lenstra attack 
> since cert hash, issuer, and serial will be all the same.

But the collision is on the *content* of the certificate computed using MD5 
while ESSCertID requires the use of SHA-1 to compute a hash over the 
*entire* certificate.

This solves the issue.

Denis

> I think NR claim ties to showing Lenstra paper and then showing that 
> forcing the subscriber to show the primes or private key to show that 
> one of the primes for a 2048 modulus is only 512 bits (should be 
> around 1024 bits).
> 
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
> Sent: Monday, March 07, 2005 3:36 AM
> To: Santosh Chokhani
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
> 
> 
> 
> Santosh,
> 
> 
>>Some of us have suggested that the Lenstra attack does not break
>>non-repudiation. I would like to add another evidence for NR.
>>
>>If there is a dispute between the signer and the relying party and the
>>signer (or CA) and the relying party produce two certificates 
>>resulting in the same hash,
> 
> 
> When RFC 3126 is used, then ESSCertID MUST be used as a signed 
> attribute
> which means that not only there MUST be the same hash value but also the 
> same CA DN and the same serial number.
> 
>     ESSCertID ::=  SEQUENCE {
>          certHash                 Hash,
>          issuerSerial             IssuerSerial OPTIONAL
>     }
> 
>     Hash ::= OCTET STRING -- SHA1 hash of entire certificate
> 
>     IssuerSerial ::= SEQUENCE {
>          issuer                   GeneralNames,
>          serialNumber             CertificateSerialNumber
>     }
> 
> Denis
> 
> 
>>signer could be required to produce further evidence for the modulii
>>and one would notice that one of the factors is 512 bits for 2048 
>>modulus, something FIPS does not recommend.  That would be viewed as 
>>additional evidence of mischief by the subscriber.
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>(703) 917-0060  Ext. 35 (voice)
>>(703) 917-0260 (Fax)
>>chokhani@xxxxxxxxxxxx
>>Visit our Web site
>>http://www.orionsec.com
> 
> 
> 
> 
>