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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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