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

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Nov 2012 09:47:14 +0000

Martin Rex <[email-masked]> writes:

>I was just plain guessing at what might have been the original motivation
>behind the addition of this useless baggage to TBSCertificate.

As others have pointed out it was added to prevent an OID-swapping attack
that's rendered irrelevant by PKCS #1 padding but is theoretically possible if
you use a sufficiently broken signature-formatting mechanism, e.g. raw RSA. My
code reads it and checks that it's a signing-capable PKC algorithm, but
doesn't do any more than that.  Since (apparently) no-one ever checks this and
so implementations that put the wrong OID in there have been deployed, this is
probably the safest thing to do.

Given all the other useless baggage in X.509 in general, I don't see its
presence as a big deal.  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.

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 14 Nov 2012 18:01:12 +0100

Hi Peter,

It would be nice to get some examples of useless baggage in X.509.

Erik Andersen

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Peter
Gutmann
Sendt: 14. november 2012 10:47
Til: [email-masked]
Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

Martin Rex <[email-masked]> writes:

>I was just plain guessing at what might have been the original 
>motivation behind the addition of this useless baggage to TBSCertificate.

As others have pointed out it was added to prevent an OID-swapping attack
that's rendered irrelevant by PKCS #1 padding but is theoretically possible
if you use a sufficiently broken signature-formatting mechanism, e.g. raw
RSA. My code reads it and checks that it's a signing-capable PKC algorithm,
but doesn't do any more than that.  Since (apparently) no-one ever checks
this and so implementations that put the wrong OID in there have been
deployed, this is probably the safest thing to do.

Peter.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Wilson <[email-masked]>
Date: Wed, 21 Nov 2012 07:44:04 +1100

It's only small but it has a staggering signal-to-noise ratio ...

I nominate the NR bit as the most useless baggage in X.509.

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.