search

rustls / webpki

WebPKI X.509 Certificate Validation in Rust
https://docs.rs/rustls-webpki/latest/webpki/
Other
97 stars 51 forks source link

Support active distrust of trust anchors #259

Closed cpu closed 4 months ago

cpu commented 4 months ago

Note: opening this as a webpki issue since it will be the enforcement point, but this issue also affects rustls/pki-types and rustls/webpki-roots. I thought there might be an existing issue for this topic, but I haven't found one

Mozilla recently announced that they intend to implement an "active distrust" for a trust anchor in the Mozilla root program. In this enforcement model the trust anchor isn't removed entirely, but instead only considered trusted for certificates issued before a drop-dead date:

In light of ECM’s persistent issues, we will be setting “Distrust After” dates for websites and email trust bits associated with ECM’s GLOBALTRUST 2020 root CA, effective June 30, 2024.

In the webpki-roots repo we have the distrust after data for participating CAs available by way of CCADB but we're missing a way to express this data in the pki_types::TrustAnchor type, and to enforce the distrust during validation in this crate: https://github.com/rustls/webpki/blob/8e0db698bf0472a84dbfe1c7bcdc847f9be61024/src/verify_cert.rs#L357

Adding a new distrust_after: Option<UnixTime> field to pki_types::TrustAnchor, populating it in webpki-roots with CCADB data, and enforcing it in verify_cert.rs seems like the most straight forward solution, but would be a breaking change in the pki_types crate. This crate is particularly avoidant of those due to the downstream ecosystem impact, so perhaps we need a different solution?

From another perspective: maybe the juice isn't worth the squeeze? Using rustls-platform-verifier gets you support for this sort of nuanced revocation (and more) out-of-box on most platforms. There are presently no other trust anchors with a "Distrust for TLS After" date in the mozilla/IncludedCACertificateReportPEMCSV report.

cpu commented 4 months ago

For completeness: Chrome's root program already announced a similar action for this root but based on SCT dates.

ctz commented 4 months ago

I would be minded to the most simple option: removing roots with any "Distrust for TLS After" from those included in webpki-roots. That is more aggressive (it would distrust existing certs that Mozilla continues to trust until their expiry) but from clicking around on crt.sh it seems the number of affected certificate in this case is very low (like 40?)

cpu commented 4 months ago

I would be minded to the most simple option: removing roots with any "Distrust for TLS After" from those included in webpki-roots.

That sounds reasonable (in this case particularly). I opened a separate issue on webpki-roots (maybe that was a mistake, bifurcating the discussion!) where I also tabled that option: https://github.com/rustls/webpki-roots/issues/72

ctz commented 4 months ago

it seems the number of affected certificate in this case is very low (like 40?)

According to https://crt.sh/cert-populations (they are listed as "e-commerce monitoring GmbH") this is 137 unexpired certificates.

cpu commented 4 months ago

Sounds good. I'll close this as not planned for now and we can take early action in webpki-roots.

I'll file an issue for a distrust after field in pki-types we can label for when we're ready to consider breaking changes. If that ever happens and there's appetite we can revive this issue.