Add Chrome Root Store index-based constraints for Merkle Tree Certs [chromium/src : main]
Matt Mueller (Gerrit)
New activity on the change![]( "Open in Gerrit")
Related details
- Nick Harper
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nick Harper (Gerrit)
Nick Harper added 1 comment![]( "Open in Gerrit")
// A leaf MTC chaining to a MtcAnchor with this constraint must not have an
// index higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_not_after = 8;
// A leaf MTC chaining to a MtcAnchor with this constraint must have an index
// higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_after = 9;Is the idea here to implement revocation (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-revocation-by-index) or log pruning (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-log-pruning)? If the former, this should be a repeated field of a message containing the start and end indices for a range of revoked indices. If the latter, only one uint64 corresponding to the "minimum index" is needed.
Also, the names index_not_after and index_after are confusing.
Related details
- Matt Mueller
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matt Mueller (Gerrit)
Matt Mueller added 1 comment![]( "Open in Gerrit")
// A leaf MTC chaining to a MtcAnchor with this constraint must not have an
// index higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_not_after = 8;
// A leaf MTC chaining to a MtcAnchor with this constraint must have an index
// higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_after = 9;Is the idea here to implement revocation (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-revocation-by-index) or log pruning (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-log-pruning)? If the former, this should be a repeated field of a message containing the start and end indices for a range of revoked indices. If the latter, only one uint64 corresponding to the "minimum index" is needed.
Also, the names index_not_after and index_after are confusing.
neither, it's intended to roughly be similar to the SCT constraints, except based on index rather than dates.
So the intended use cases would be things like distrust events (index_not_after), or enforcing additional constraints but only after a certain point(index_after + permitted_dns_names).
The naming is also this way to be similar to the sct_not_after and sct_all_after naming.
Related details
- Nick Harper
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nick Harper (Gerrit)
Nick Harper added 1 comment![]( "Open in Gerrit")
// A leaf MTC chaining to a MtcAnchor with this constraint must not have an
// index higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_not_after = 8;
// A leaf MTC chaining to a MtcAnchor with this constraint must have an index
// higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_after = 9;Matt MuellerIs the idea here to implement revocation (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-revocation-by-index) or log pruning (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-log-pruning)? If the former, this should be a repeated field of a message containing the start and end indices for a range of revoked indices. If the latter, only one uint64 corresponding to the "minimum index" is needed.
Also, the names index_not_after and index_after are confusing.
neither, it's intended to roughly be similar to the SCT constraints, except based on index rather than dates.
So the intended use cases would be things like distrust events (index_not_after), or enforcing additional constraints but only after a certain point(index_after + permitted_dns_names).
The naming is also this way to be similar to the sct_not_after and sct_all_after naming.
How about combining the needs of something roughly similar to SCT constraints with the range revocation feature?
For an sct_all_after (or index_after) equivalent, that would match a revoked range of (0, index_after). For an sct_not_after (or index_not_after) equivalent, that would be a revoked range of (index_not_after, uint64_max).
Related details
- Matt Mueller
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matt Mueller (Gerrit)
Matt Mueller added 1 comment![]( "Open in Gerrit")
// A leaf MTC chaining to a MtcAnchor with this constraint must not have an
// index higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_not_after = 8;
// A leaf MTC chaining to a MtcAnchor with this constraint must have an index
// higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_after = 9;Matt MuellerIs the idea here to implement revocation (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-revocation-by-index) or log pruning (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-log-pruning)? If the former, this should be a repeated field of a message containing the start and end indices for a range of revoked indices. If the latter, only one uint64 corresponding to the "minimum index" is needed.
Also, the names index_not_after and index_after are confusing.
Nick Harperneither, it's intended to roughly be similar to the SCT constraints, except based on index rather than dates.
So the intended use cases would be things like distrust events (index_not_after), or enforcing additional constraints but only after a certain point(index_after + permitted_dns_names).
The naming is also this way to be similar to the sct_not_after and sct_all_after naming.
How about combining the needs of something roughly similar to SCT constraints with the range revocation feature?
For an sct_all_after (or index_after) equivalent, that would match a revoked range of (0, index_after). For an sct_not_after (or index_not_after) equivalent, that would be a revoked range of (index_not_after, uint64_max).
The range revocation requires the MtcMetadata component data to be loaded. In a future where we also support full MTCs that can verify without the MtcMetadata, that wouldn't be sufficient.
It also doesn't address the second use case (adding constraints, rather than distrusting).
Related details
- Nick Harper
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nick Harper (Gerrit)
Nick Harper voted and added 2 comments![]( "Open in Gerrit")
Votes added by Nick Harper
| Code-Review | +1 |
2 comments
// Both index_not_after and index_after cases:Should there be a test case with index_after >= index_not_after? That would be an invalid constraint because it's never satisfiable, so an answer of "no" is fine.
// A leaf MTC chaining to a MtcAnchor with this constraint must not have an
// index higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_not_after = 8;
// A leaf MTC chaining to a MtcAnchor with this constraint must have an index
// higher than the specified value. Ignored if specified on a classical
// TrustAnchor.
optional uint64 index_after = 9;Matt MuellerIs the idea here to implement revocation (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-revocation-by-index) or log pruning (https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-10.html#name-log-pruning)? If the former, this should be a repeated field of a message containing the start and end indices for a range of revoked indices. If the latter, only one uint64 corresponding to the "minimum index" is needed.
Also, the names index_not_after and index_after are confusing.
Nick Harperneither, it's intended to roughly be similar to the SCT constraints, except based on index rather than dates.
So the intended use cases would be things like distrust events (index_not_after), or enforcing additional constraints but only after a certain point(index_after + permitted_dns_names).
The naming is also this way to be similar to the sct_not_after and sct_all_after naming.
Matt MuellerHow about combining the needs of something roughly similar to SCT constraints with the range revocation feature?
For an sct_all_after (or index_after) equivalent, that would match a revoked range of (0, index_after). For an sct_not_after (or index_not_after) equivalent, that would be a revoked range of (index_not_after, uint64_max).
The range revocation requires the MtcMetadata component data to be loaded. In a future where we also support full MTCs that can verify without the MtcMetadata, that wouldn't be sufficient.
It also doesn't address the second use case (adding constraints, rather than distrusting).
Discussed this further in a doc. This framing of the constraints LGTM.
Related details
- Matt Mueller
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matt Mueller (Gerrit)
Matt Mueller voted and added 2 comments![]( "Open in Gerrit")
Votes added by Matt Mueller
| Commit-Queue | +1 |
2 comments
+chrome/browser/component_updater/OWNERS
Should there be a test case with index_after >= index_not_after? That would be an invalid constraint because it's never satisfiable, so an answer of "no" is fine.
Agreed that these are "invalid" cases, but since we don't otherwise really guarantee it won't happen, I added some tests of that that.
Related details
- Sorin Jianu
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sorin Jianu (Gerrit)
Sorin Jianu voted and added 1 comment![]( "Open in Gerrit")
Votes added by Sorin Jianu
| Code-Review | +1 |
1 comment
- Matt Mueller
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matt Mueller (Gerrit)
Matt Mueller voted Commit-Queue+2![]( "Open in Gerrit")
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
Add Chrome Root Store index-based constraints for Merkle Tree Certs
- M chrome/browser/component_updater/pki_metadata_component_installer_browsertest.cc
- M net/cert/cert_verify_proc_builtin.cc
- M net/cert/cert_verify_proc_builtin_unittest.cc
- M net/cert/internal/trust_store_chrome.cc
- M net/cert/internal/trust_store_chrome.h
- M net/cert/internal/trust_store_chrome_unittest.cc
- M net/cert/root_store.proto
- M net/data/ssl/chrome_root_store/test_store.textproto
- M net/tools/root_store_tool/root_store_tool.cc
Code-Review: +1 by Nick Harper, +1 by Sorin Jianu
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |