Looking at the Technical Report [1], I am confused...
First bullet under Root Causes:
"The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client."
So, if I understand correctly, the assumed process was: Root signs Intermediate --> Intermediate signs Add-on (whether Intermediate is valid or not) --> FF only validates the End-entity is within date range.
Is this the correct procedure? You're telling me that the intended behavior is that FF allows add-ons signed by an expired cert? If that is the case, then what is the point of the signing system in the first place?
Additionally, third paragraph under Recommendations:
"Second, if we are committed to the current PKI and add-on signing approach, [...]"
'_If_ we are committed' is non-absolute. Is the FF team actually set on this approach?
> You're telling me that the intended behavior is that FF allows add-ons signed by an expired cert?
The leaf certificate is specific to a particular instance of an addon. Firefox has a separate, more flexible capability called the blocklist that can disable individual addons. Since the blocklist exists, enforcing expiration dates on the leaf certificates wouldn't help in any way, but it would require re-signing and re-distributing all addons periodically. So, yes it was a deliberate decision to ignore expiration dates on leaf certificates.
> If that is the case, then what is the point of the signing system in the first place?
"FF only validates the End-entity is within date range"
No, this was disabled back in 2016. The technical report briefly had this worded wrong, sorry if you read it before it was corrected.
"what is the point of the signing system in the first place?"
Like the technical report describes, things like "monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root."
So, the intended behavior is that FF does not check any Add-on related cert for a valid date range? In that case, what prevents an insider threat of a Mozilla employee signing malicious add-ons with an out-of-date cert?
When you sign software with certificates that can expire, you run into the problem that software can stop working with no change on the user's end whatsoever. And of course, the shorter the expiry on code-signing certificates, the worse this problem becomes.
The solution for systems like Java and Authenticode is for Certificate Authorities to also offer a 'Trusted Timestamping' service, which certifies that the software existed at a time when the code-signing certificate was valid.
In Java's case, as the CA providing the timestamp is already trusted issue code-signing certificates with arbitrary dates, this doesn't add any new trusted parties.
First bullet under Root Causes:
"The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client."
So, if I understand correctly, the assumed process was: Root signs Intermediate --> Intermediate signs Add-on (whether Intermediate is valid or not) --> FF only validates the End-entity is within date range.
Is this the correct procedure? You're telling me that the intended behavior is that FF allows add-ons signed by an expired cert? If that is the case, then what is the point of the signing system in the first place?
Additionally, third paragraph under Recommendations:
"Second, if we are committed to the current PKI and add-on signing approach, [...]"
'_If_ we are committed' is non-absolute. Is the FF team actually set on this approach?
1: https://wiki.mozilla.org/Add-ons/Expired-Certificate-Technic...
Edit: clarifications