9

Section 4.1 of RFC 5280 defines the contents of an x509 Certificate. Specifically, two fields are listed (signatureAlgorithm and signature) and defined to contain the same information: AlgorithmIdentifier:

4.1.  Basic Certificate Fields

  The X.509 v3 certificate basic syntax is as follows.

  Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,            <------
        signatureValue       BIT STRING  }

  TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,            <------
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
     <-~- truncated -~->

Later, in Section 4.1.1.2, signatureAlgorithm is defined as:

4.1.1.2. signatureAlgorithm

The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. ... This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3).

And in Section 4.1.2.3, signature is defined as:

4.1.2.3. Signature

This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate.

This field MUST contain the same algorithm identifier as the SignatureAlgorithm field in the sequence Certificate (Section 4.1.1.2).

My question is: Why must the same piece of information be listed twice?

I could understand wanting to include the Hash algorithm and Signature generation method in the Certificate Data section so it gets included with the signature verification and is therefore not susceptible to changes.

But if that is the case, why list it again between the Certificate Data and Signature sections?

I came across other questions that seem to ask the same thing, but I did not find an answer that specifically spoke to why it is listed twice. Just that it must be listed twice.

  • 1
    I'd be tempted to reply "because X509 is a heap of poo designed by (several) committee" but maybe there is a non-kafkaian answer. – Stephane Feb 16 '16 at 7:51
3

I think it's a protection against certain kind of cryptographic attacks called "algorithm substitution attacks".

Please take a look here: Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute (RFC6211)

As briefly explained here: https://tools.ietf.org/html/rfc6211

In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process.

I think it's exactly what you are looking for :)

Cheers !

Edit: Edited to add the "I think".

Edit 2: Found out that the question is duplicated... From this post: https://security.stackexchange.com/a/24796 Relating the "TBSCertificate.signature" field:

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).

  • 2
    This is great. And it is almost the answer I am looking for. There is a question that remains: why include it outside of the signature portion? Why not just list it once inside the section of the certificate that is included in the hash for the signature? Wouldn't that be sufficient in preventing someone from modifying the algorithm field? How is listing it twice safer? – Eddie Feb 22 '16 at 1:51
  • You are right. Here you have :D security.stackexchange.com/a/24796 I'll edit and add the explanation from that post. – BBerastegui Feb 22 '16 at 5:01
  • 1
    Thanks for the link, that is some useful contribution. I've +1'd your answer, because you definitely deserve it. That said, I think the root question still remains unanswered. Why have a Signature Algorithm defined outside of the TBS certificate field at all? Why not only have the one inside the TBS certificate? – Eddie Feb 22 '16 at 16:12
  • From: 3gpp.org/tsg_t/WG2_Capability/SWG1/SWG1_10_Athens/Docs/… "(...) there is some unsigned information in a certificate: the signature itself, the signature algorithm identifier (actual appears twice, once signed and once unsigned)" There is one part of the certificate that is not signed (where one of the algorithm signatures is) that will not affect the hash used in the signature verification. Full expl. on the previous document & more info about this here: bugzilla.mozilla.org/show_bug.cgi?id=1077864 – BBerastegui Feb 23 '16 at 3:22
  • 1
    Sorry, I just got your point after digging into this... I can't find out why having the dupped signature algorithm outside the signed portion of the certificate. I'll try to find out and I'll reach you back :D – BBerastegui Feb 23 '16 at 3:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.