[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Santosh,


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.
No revision will be necessary, since RFC 3126 alrady includes that option in section "3.8.2 Other Signing Certificate Attribute Definition". I copy that section underneath: 

   The following attribute is identical to the ESS SigningCertificate
   defined above except that this attribute can be used with hashing
   algorithms other than SHA-1.

   This attribute must be used in the same manner as defined above for
   the ESS SigningCertificate attribute.

   The following object identifier identifies the signing certificate
   attribute:

   id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) id-aa(2) 19 }

   The signing certificate attribute value has the ASN.1 syntax
   OtherSigningCertificate

   OtherSigningCertificate ::=  SEQUENCE {
       certs        SEQUENCE OF OtherCertID,
       policies     SEQUENCE OF PolicyInformation OPTIONAL
                    -- NOT USED IN THIS DOCUMENT
   }

   OtherCertID ::= SEQUENCE {
        otherCertHash            OtherHash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   OtherHash ::= CHOICE {
       sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
       otherHash OtherHashAlgAndValue
   }

   OtherHashValue ::= OCTET STRING

   OtherHashAlgAndValue ::= SEQUENCE {
     hashAlgorithm  AlgorithmIdentifier,
     hashValue      OtherHashValue
   }


Denis


-----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