←back to thread

1318 points xvector | 1 comments | | HN request time: 0.203s | source
Show context
tzs ◴[] No.19824017[source]
I'm a bit confused.

I thought that the way signing works in general is that the signer issues a certificate for the thing being signed (domain, code, whatever) that contains identifying information for the thing signed (host name for an SSL certificate, checksum of the code for a code signing certificate), the valid from and valid to dates of that certificate, and assorted other information, and either a reference to or a copy of the signer's certificate, and it signs the whole issued certificate with the signer's certificate.

Someone checking the signed thing is supposed to consider it validly signed if:

1. The date is in the valid range for the signed thing's certificate,

2. A check of the signature of that certificate against the signing certificate passes,

3. The signing certificate is recognized as being from an issuer considered trusted by the checker,

4. Neither the signed thing's certificate nor the signing certificate have been revoked, and

5. The signing took place during the valid date range of the signing certificate.

Note there is no "the date of the check is in the valid date range of the signing certificate". A signing certificate expiring should not invalidate things signed by it. It should just prevent signing anything else with it.

So why is a signing certificate expiring for Firefox breaking already signed extensions? Shouldn't it just be stopping new versions of extensions from being signed?

replies(2): >>19824046 #>>19824207 #
1. geofft ◴[] No.19824046[source]
If a signing certificate expires and is stolen, it can backdate signatures. On the theory that expiration is useful because either people keep poorer track of key material over time or algorithms get weaker over time (which is not an unassailable theory, but it's a coherent model), you want expiration to prevent future use just as if it were revocation. Because you can't trust the date of a possibly-forged signature, you have to check the current date.

The model you're suggesting is closer to the "timestamping" one commonly used in code signing (IIRC Windows and Mac both do this) where a third party that's particularly trusted to handle key material well long-term gives you a second signature over the message "I saw this signature at this time" (effectively they are analogous to a notary or witness for real-world signatures). Then you can trust that signatures from expired signing certs were actually made in the past, and not by an attacker who got hold of the key. That is, without timestamping you have no proof of #5 in your list.

(I suppose you could do this now for the SSL PKI with Certificate Transparency logs.... it isn't exactly what they were built for but it's probably sound.)