Why is the signatureAlgorithm field in X.509 certificates redundant?

See the ASN.1 description of an X.509 certificate below:

Certificate ::= SEQUENCE {
tbsCertificate      TBSCertificate ({ x509_note_tbs_certificate }),
signatureAlgorithm  AlgorithmIdentifier,
signature       BIT STRING ({ x509_note_signature })
}

TBSCertificate ::= SEQUENCE {
version           [ 0 ] Version DEFAULT,
serialNumber        CertificateSerialNumber ({ x509_note_serial }),
signature       AlgorithmIdentifier ({ x509_note_pkey_algo }),
issuer          Name ({ x509_note_issuer }),
validity        Validity,
subject         Name ({ x509_note_subject }),
subjectPublicKeyInfo    SubjectPublicKeyInfo,
issuerUniqueID    [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID   [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL,
extensions        [ 3 ] Extensions OPTIONAL
}


What's the difference between Certificate.signatureAlgorithm and TBSCertificate.signature?

They appear to have the same value, and Certificate already includes a TBSCertificate in it, so one of the values is redundant.

Why is it included then?

From RFC 5280 r.e TBSCertificate.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).

I think it's because the authoritative signature is on the contents of TBSCertificate. If the signature algorithm used by the CA weren't included in the certificate to be signed then maybe one could change the Certificate.signatureAlgorithm field to something more amenable to a would-be adversary.

A similar answer has been given before on security.SE

• Just saw your answer after posting mine... However, I am not sure whether this is the actual reason. If this would be the reason, one could simply remove the Certificate.signatureAlgorithm field and instead always rely on the TBSCertificate.signature field to get rid of the redundancy.
There is no difference. RFC 5280 even requires $$\tt signatureAlgorithm$$ and $$\tt signature$$ to be the same.
According to this discussion on the PKIX mailing list, the reason for the redundancy is that it allows to consistently process signatures independent of the signed data, e.g., verifying the signature without knowing about the structure of $$\tt TBSCertificate$$.