A few comments and nits are below but I have one high level question. Why limit the manifest produced by root programs to trust anchors? Root programs could produce a structure that represents CA certificates and all possible partial paths that can be validated by a trust store as well. This would remove the need for CAs or subscribers (or anyone who used the root program) to do path building. Root program users could look up paths that end with the issuer of a given certificate then validate using the corresponding trust store. This approach may remove the need for CAs to take any action relative to this mechanism and should require fewer moving parts to move in concert. The signaling mechanism seems like something that is long overdue, and I don't think would need to change if the manifest were augmented. Though, if CA certs were included in the manifest, indices could be returned instead of CA certs to represent the path, which may be useful in the PQ scenario.
Questions/Comments In section 4, the ability to drop old versions seems like a need-to-have over time. If preserving indexing is the concern, maybe define the versions field as featuring an array of trust-store-version or null. In section 4, why include entire TAs in the manifest instead of a reference (i.e., hash)? Including the TAs may promote misuse. If TAs are necessary, CBOR may be a better choice given the bulk of the contents are binary data. In section 4.1, the sum may exceed the lifetime of the trust anchor. For example, if a trust anchor is five years from decommissioning when expiration is calculated but its max_lifetime per current definition is six years. Should max_lifetime be the number of seconds of the maximum lifetime of subscriber certificates issued by subordinate/leaf CAs? In section 4.2, why not use indices to identify each trust anchor and limit the usage of labels to the optional grouping of TAs? This may help eliminate possible mistakes when a relying party prepares an exclusion list, i.e., by referencing a group when an individual TA was intended. Does "repurpose" include adding or removing a trust anchor from a label or can label members vary freely across versions? In section 5, it's not clear to me that exclusively tasking CAs with preparing CertificatePropertyLists is desirable. If a CA is not aware of a root program a subscriber needs to support, the subscriber could prepare the structure directly (possibly by augmenting a structure provided by the CA as a hint). Paths with more than one intermediate CA may complicate preparation for CAs as well. In section 6.5, the second and third paragraphs (and security considerations) suggest the root program prepares trust expressions but the next to last paragraph suggests software versions influence trust expression contents. Requiring root programs to be aware of software versions seems like a stretch. Trust expressions seem inherently local, i.e., to capture trust anchors a relying party has explicitly disabled. There is also potential for a relying party to utilize trust anchors from more than one root program, which would require relying party to do final preparation. Re: the "should get moved to the manifest" note, why is the ability to omit a TA from the entries list not sufficient for this? Nits In 2.2, a trust anchor typically also has a name in addition to a key. In last bullet of section 3, ‘all’ seems like an either an overstatement or a tautology. Maybe "...assured that relying parties with compatible trust stores will be satisfied..." or just delete. In section 4, the "expected to issue" in the max_lifetime definition should be "expected to validate". It probably means "subscriber certificates" instead of "certification paths", as well. Section 4.1 "all unexpired certificates" should probably be "all unexpired subscriber certificates." In the last paragraph of 4.2, the "MAY repurpose...after" should be "MUST NOT repurpose...before" relative to expiration of all references. If label reuse is the primary motivation for expiration, is expiration worth the complexity? In section 5, the entry sorting language should indicate ascending or descending. In 6.2, it may be worth adding "and MUST use one of the trust anchor stores indicated in the trust_expressions extension to validate the result." Section 6.5 should define "desired subset." It should also relate "trust store version" and "specified version" in steps 2 and 3 to the actual trust store that a relying party is using. It seems a bit odd not to factor in comparison of manifest contents against the trust store used for path validation when preparing the excluded_labels list. As noted above, the last sentence of the security considerations section doesn't seem necessary. In Appendix A, the type field may be better as a group socket than text. Do you intend to make Appendix A normative at some point? From: TLS <tls-boun...@ietf.org> on behalf of David Benjamin <david...@chromium.org> Date: Thursday, October 19, 2023 at 11:38 AM To: "<tls@ietf.org>" <tls@ietf.org> Cc: Devon O'Brien <asymmet...@google.com>, <b...@chromium.org> Subject: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt Hi all, We just published a document on certificate negotiation. It's a TLS extension, which allows the client to communicate which trust anchors it supports, primarily focused on use cases like the Web PKI where trust stores are fairly large. There is also a supporting ACME extension, to allow CAs to provision multiple certificate chains on a server, with enough metadata to match against what the client sends. (It also works in the other direction for client certificates.) The hope is this can build towards a more agile and flexible PKI. In particular, the Use Cases section of the document details some scenarios (e.g. root rotation) that can be made much more robust with it. It's very much a draft-00, but we're eager to hear your thoughts on it! David, Devon, and Bob ---------- Forwarded message --------- From: <internet-dra...@ietf.org> Date: Thu, Oct 19, 2023 at 11:36 AM Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt To: Bob Beck <b...@google.com>, David Benjamin <david...@google.com>, Devon O'Brien <asymmet...@google.com> A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-trust-expr Revision: 00 Title: TLS Trust Expressions Date: 2023-10-19 Group: Individual Submission Pages: 35 URL: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt Status: https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/ HTML: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr Abstract: This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
