As Mozilla has stopped caring about code signatures, e-mails are much
more relevant for checking old certificates as of a known date:
Most e-mail systems provide the reader with a locally verified record of
when exactly the mail contents reached a trusted mail server and/or a
POP3 client. Thus validating e-mail signatures as of that date is
perfectly sensible, either via a code improvement in Thunderbird or via
a knowledgeable user comparing the expiry time in error messages to the
mail server timestamp visible via "view source".
Some CAs also offer (as a paid service) to provide anonymous timestamp
signatures for use on signed documents, these should be technically
compatibible with use on e-mail signatures or entire e-mails, though
that procedure isn't very common.
I don't know if gMail implements these features in their web and app
interfaces, but they certainly could if they so wanted, and with
Google's habit of keeping stored data, the features could probably be
retroactively applied to mails received long before the feature was
implemented.
On 15/07/2019 03:11, Samuel Pinder wrote:
The way I understand it is, generally speaking, Root CAs may be kept in a
root store for as long as the root key material is not compromised in any
way. In practice Root CA certificates are removed at the operator's request
when they believe it is no longer needed, or the root store operator
believes it should be removed due to the key material being vulnerable to
brute forcing, or some other policy reason (e.g. violation or misuse). Of
course it is possible for renewed Root CA certificates to replace older
ones as long as they are signed with the same key material- allowing
everything else chained to it still be valid (I've seen this happen once
with the "GlobalSign Root CA" originally published back in 1998.)
While keeping expired Root CAs may not useful for web server certificates
chaining up to an expired CA certificate, it is useful for codesigning
certificates. Timestamped codesigned objects can continue to work after
their certificate has expired as the "timestamp" shows that a certificate
was valid *at the time it performed the signature*. Have a look here:
https://serverfault.com/questions/878919/what-happens-to-code-sign-certificates-when-when-root-ca-expires
.
Samuel Pinder
On Mon, Jul 15, 2019 at 1:32 AM Vincent Lours via dev-security-policy <
[email protected]> wrote:
On Monday, 15 July 2019 04:41:12 UTC+10, Ryan Sleevi wrote:
Thanks for mentioning this here.
Could you explain why you see it as an issue? RFC 5280 defines a trust
anchor as a subject and a public key. Everything else is optional, and
the
delivery of a trust anchor as a certificate does not necessarily imply
the
constraints of that certificate, including expiration, should apply.
Hi Ryan,
Thanks for your message.
First of all, I never said that was an issue. I was just reporting some
expired Root CA, as I was thinking that may impact peoples.
Secondly, I was not aware of the RFC 5280 defining a trust anchor as a
subject and a public key.
However, if you referrer to the same RFC, they defined a Public Key in the
"4.1.2.5. Validity" Section:
"When the issuer will not be able to maintain status information until
the notAfter date (including when the notAfter date is
99991231235959Z), the issuer MUST ensure that no valid certification
path exists for the certificate after maintenance of status information
is terminated.
This may be accomplished by expiration or
revocation of all CA certificates containing the public key used to
verify the signature on the certificate and discontinuing use of the
public key used to verify the signature on the certificate as a trust
anchor."
In the case of the "certdata.txt", this file is including Public CA
certificates. So an expired certificate means that the key cannot be used
anymore.
I'm still not expressing this message as an issue, but an suggestion to
update/remove those expired Public Keys from your certdata.txt.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
