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

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Nov 2012 10:01:34 +0000

I wrote:

>If we wanted to remove all the stuff that isn't baggage there'd be very
>little left: A DNS name or email address, a link to the signing cert for
>verification purposes, a key usage flag, some sort of advertising field for
>the CA, and a signature.

Sorry, hit ^D too quickly: We'd also need some sort of FUOU field for the DoD
crowd alongside the other bits.

Peter.

---

From: "Andris Berzins" <[email-masked]>
Date: Thu, 15 Nov 2012 22:31:56 +0200

Does there exist a signature algorithm (e.g., MD4withRSA) that is known or suspected to be forgeable (using Dobbertin or other attacks)?

If so, does PKIX maintain a whitelist of unforgeable signature algorithms such that if verifiers support only whitelisted algorithms, the inner identifier is redundant?

As we currently have discussed, inner identifier will not help you in case of forgeable MD4withRSA. What helps is PKCS#1 v.15 signature that contains identifier.

If there is a nonempty set of forgeable algorithms supported by any verifier application claiming to be X.509 or PKIX conformant, then either the algorithm whitelist must exist and be included in X.509 conformance, or the inner/outer MUST requirement is justified.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 16 Nov 2012 01:32:30 +0000

Dan Brown <[email-masked]> writes:
>Peter Gutmann [mailto:[email-masked]] writes:
>> Dan Brown <[email-masked]> writes:
>>
>> >Burt Kaliski prepared some slides:
>>
>> >http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewalls/kaliski-hash-firewalls-ct-rsa-2002.ppt
>>
>> None of those applied to PKCS #1, or any newer replacements like PSS.

>Slide 27 describes an attack that involves "registering" a malicious OID for
>a strong hash.

While that's a theoretical weakness, the chances of registering a really odd-
looking OID for a signature algorithm and then persuading Microsoft, Mozilla,
and Google to adopt it is roughly, oh, zero.  This could make it the Mongolian
Stupidity Test of crypto (the original Mongolian Stupidity Test was "Can I
borrow your sword?").

>Don't do what?  Use "some other signatures schemes"?

Yeah.  If you're currently using PKCS #1 then don't suddenly switch to ISO
9796 with its track record of problems (and non-use in pretty much any
Internet standard, although it is used by banks in Europe), or GQ, or
something else.

>The question about redundancy of the OIDs can be rephrased as follows.  Is it
>possible for an attacker to forge a certificate that is valid except that
>inner and outer signature algorithm identifiers do not match.

We need to distinguish between "is it possible" and "is it practical".  If you
set up the conditions just right then yes, it's possible.  Mind you it's also
possible to forge any signature of any kind, you just need a lot of time.
However in terms of asking "is it practical", against currently-deployed
mechanisms, no, and future ones will be even more resistant to this since we
know a lot more about signature mechanism design now than we did 
twenty years ago.

Peter.