4
$\begingroup$

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?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
6
$\begingroup$

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

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ 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. $\endgroup$
    – dade
    Commented Jan 23, 2018 at 11:42
  • $\begingroup$ Allowing consistent signature processing seems like the most justifiable answer, I'd go with that! There's not really any cryptographic reason. $\endgroup$
    – Chris
    Commented Jan 23, 2018 at 11:52
6
$\begingroup$

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

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ It would also allow you to start hashing before parsing the TBSCertificate structure I presume. This would be useful in streaming implementations. That said, storing a certificate in randomly accessible memory should be no problem in most runtime environments, so the need for streaming a certificate clearly isn't there. I'm not sure how much of an advantage there is of signing the signature algorithm; having to deal with two identifiers in one signes itself is harder than just one, but it remains to be seen by how much. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jan 23, 2018 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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