7

From the X.509 RFC:

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,

Seems to me that tbsCertificate -> signature and signatureAlgorithm are redundant? That they should always be the same?

As such why include both? Why not just include one or the other?

Improve this question

1 Answer 1

Reset to default
8

Both fields should be identical. The redundancy was apparently meant to defeat an obscure attack vector relying on weaknesses that existing signature algorithms do not have, and for unspecified goals. As Peter Gutmann says in his X.509 style guide, when talking about the signature field in the TBS:

There doesn't seem to be much use for this field, although you should check that the algorithm identifier matches the one of the signature on the cert (if someone can forge the signature on the cert then they can also change the inner algorithm identifier, it's possible that this was included because of some obscure attack where someone who could convince (broken) signature algorithm A to produce the same signature value as (secure) algorithm B could change the outer, unprotected algorithm identifier from B to A, but couldn't change the inner identifier without invalidating the signature. What this would achieve is unclear).

A sane implementation of X.509 certificate validation will use the outer field (signatureAlgorithm) to verify the signature, and will just check afterwards that the inner signature field matches the outer field (but failing to do that last verification will not actually harm security).

Improve this answer
3
  • I asked a very similar question, and was referred to this one. Using the terminology of your quote, I have a follow on question: Why have the outer unprotected algorithm field at all? Why not solely use the inner, protected, algorithm field to identify what signature algorithm was used to sign the certificate?
    – Eddie
    Feb 22, 2016 at 16:14
  • 1
    That the algorithm identifier is inner or outer does not really matter. If you use only secure algorithms with public keys properly associated to signers identities, then there is no gain in having the signature identifier part of the signed data. If you accept to use an insecure algorithm, then that is what you need to fix, and adding the algorithm identifier to the signed data is unlikely to save the day.
    – Thomas Pornin
    Feb 22, 2016 at 16:47
  • 1
    Yes. That makes sense. Either way the Client must only accept secure algorithms. But I'm still curious as to why they put the same information in the x509 certificate twice. My best guess is there is some value of having the algorithm identifier in the protect part of the certificate, but then I have no answer to why it exists outside the protected part at all.
    – Eddie
    Feb 22, 2016 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .