2

From my understanding, the whole point of the root / trusted store (in a device, in a computer, on a server...) is that "the trust starts here". In other words, hacking, etc. aside, in theory all certificates in the trusted store don't need to be -- and really can't be -- "verified" per se; they are trusted implicitly simply by virtue of the fact that they reside in the trusted store.

So here is my question: do these certificates even need to be signed (from a security standpoint, not from a perspective of software implementations of certificate chain verification)? I guess more specifically, my question is this: does the digital signature on a certificate in the trusted store provide an added security benefit?

The only reason I could imagine these certificates need signatures is simply to make trust / verification easier, i.e. elimiate special cases in verification software -- all certificates must be signed, even if the signature of the certificate at the start of the chain is essentially meaningless.

4
  • 1
    What about checking if the certificate has been altered?
    – schroeder
    Feb 9, 2017 at 19:43
  • @schroeder - I suppose... but if you're going to alter the cert (e.g., the public key, the expiration date, etc), couldn't you just re-sign the certificate anyway?
    – Dan
    Feb 9, 2017 at 20:03
  • 1
    It eliminates special cases in a range of software, not just validation but also import/export, UI/display/logging, and (usually) transmission. But as you deduce and Steffen confirms, no security benefit. Feb 10, 2017 at 13:14
  • Yes, after you put the certificate in the trusted store the signature has played its role. But before you put it there the signature is definitely needed, at the very least to verify that the certificate has been transported without tampering.
    – pgianna
    Feb 10, 2017 at 14:51

2 Answers 2

4

Your assumption is true: certificates in the trust store are trusted only because they are in the trust store and not because they are signed by somebody (usually themselves, i.e. self-signed). That's why it is also not seen as a problem if there are certificates in the trust store which still have a SHA-1 signature, since this signature does not add any security anyway in this case.

1
  • Thank you for responding... I was wondering if there was something fundamental I was missing. Good point about the SHA-1 hashes in the trust store.
    – Dan
    Feb 10, 2017 at 0:13
1

RFC 3280 mentions a possible security purpose (emphasis mine):

... where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.)

The way I read this is that if you, a human, are handed a "CA root cert" that doesn't even have a valid self-signature, you SHOULD be suspicious they're incompetent ;-)

  • Note that IIUC the certs CAs recommend people to add to their trust store are frequently not actual self-signed roots but cross-signed certs.

But I don't see anywhere this is a requirement for software to trust the cert. All it needs is a "trust anchor". Section 6.1 Basic Path Validation defines explicitly the inputs that matter:

(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes:

  1. the trusted issuer name,
  2. the trusted public key algorithm,
  3. the trusted public key, and
  4. optionally, the trusted public key parameters associated with the public key.

The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure.

(emphasis mine again)

You must log in to answer this question.

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