Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

From: "Andris Berzins" <[email-masked]>
Date: Wed, 14 Nov 2012 10:58:45 +0200

Quoting "Kemp, David P." <[email-masked]>:
> See RFC 6211

"In an algorithm substitution attack, the attacker looks for a different algorithm that produces the same result as the 
algorithm used by the signer.  As an example, if the creator of the message used SHA-1 as the digest algorithm to 
hash the message content, then the attacker looks for a different hash algorithm that produces a result that is of the 
same length, but with which it is easier to find collisions."

Again, if the attacker can find colliding tbsCertificate content, he can as well substitute AlgID in his colliding 
tbsCertificate. Placing AlgID in content that will be hashed and then signed does not seem to help against algorithm 
substitution attack. Placing AlgID directly under the signature as it is done in PKCS#1 v.15 signature does actually 
help against digest substitution attack.

Tell me what I am missing here.

> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mart
>in Rex
> Sent: Tuesday, November 13, 2012 5:59 PM
> To: Andris Berzins
> Cc: [email-masked]
> Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates
> 
> Andris Berzins wrote:
>> 
>>> While the original idea might have been that one wanted to support
>>> ambiguous AlgId parameters that would have needed integrity
>>> protection,
>> 
>> Why would integrity of AlgId parameters matter?
> 
> I honestly don't know.  I was just plain guessing at what might have been th
>e original motivation behind the addition of this useless baggage to TBSCert
>ificate.  As I wrote, I believe that MUST in section 4.1.2.3 of rfc3280, and
> its successor rfc5280 is silly.
> 
> 
>> 
>> If using arbitrary AlgId parameters would allow to forge signature,
>> then forger could just put AlgId he needs under the forged signature.
> 
> Probably.
> 
> 
> -Martin
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Thu, 15 Nov 2012 03:34:50 +0100 (CET)

Andris Berzins wrote:
> "Kemp, David P." <[email-masked]>:
>>
>> See RFC 6211
> 
> "In an algorithm substitution attack, the attacker looks for a different
> algorithm that produces the same result as the algorithm used by the
> signer.  As an example, if the creator of the message used SHA-1
> as the digest algorithm to hash the message content, then the attacker
> looks for a different hash algorithm that produces a result that is of the 
> Again, if the attacker can find colliding tbsCertificate content,
> he can as well substitute AlgID in his colliding tbsCertificate.
> Placing AlgID in content that will be hashed and then signed does
> not seem to help against algorithm substitution attack. Placing AlgID
> directly under the signature as it is done in PKCS#1 v.15 signature
> does actually help against digest substitution attack.
> 

I believe your observation is correct.

If you look at the MD5 collision attack to produce the rogue SSL CA cert,
it would have exactly ZERO impact for the attackers if they would have
to modify the signatureAlgorithm parameter within TBSCertificate
(along with all the other stuff that they modify inside the cert).

What did/does provide mitigation is the Hash-OID inside PKCS#1 v1.5,
and the randomizing of the serial number that was adopted by the
CABforum Baseline Requirements as a result of this proof-of-concept
rogue SSL CA cert creation.

-Martin

PS: I haven't reviewed or evaluated rfc6211, but I would not be surprised
    if it turns out to not provide any additional security.