DavidBen's tweak

Realistically, Web PKIs are likely going to continue be evaluated by both Web Clients(TM) and long, long tail of web-adjacent clients of increasing distance to The Web(TM).

Of course, as with today, there is some point at which, on a per-application basis, the application will decide it's better off using a PKI tailored to its needs than one tailored for the Web's needs. But I think it's pretty likely that, like today, there will be some clients that overlap in PKI but don't care to manage a second set of trusted parties to get transparency guarantees. (I also would like more of the long tail to enforce transparency, but there's no escaping the fact that more trusted parties => more overhead to manage them.)

MTC accommodates this, and it's really not hard to accommodate this: allow clients to be configured with just the CA cosigner, and no additional cosigner requirement. But that means MTC doesn't ensure this property, because it allows such clients. It just makes it possible to ensure this property.

Co-authored-by: David Benjamin <davidben@google.com>

Author: bwesterb

charter-ietf-plants.md

@@ -28,6 +28,6 @@ As part of this work, the Working Group may extend PKIX (RFC 5280), e.g. with ne
 
 Though not the initial focus, the PLANTS Working Group may consider other properties of transparent PKIs to improve upon the status quo, such as auditing, monitoring, or revocation. If feasible concrete improvements are identified, the Working Group may recharter to seed secondary deliverables that build on its initial work.
 
-In evaluating decisions and design tradeoffs, the Working Group will consider security, privacy, transparency, performance, and deployment properties, aiming to comparably meet the needs of today's applications that use CT-based PKIs with TLS. In particular the WG will deliver a design that ensures that a misbehavior by a single party cannot compromise transparency for relying parties. The Working Group may consider how these mechanisms may apply to other PKIs or non-interactive protocols, but these will not be the primary use case and may ultimately have different requirements or limitations.
+In evaluating decisions and design tradeoffs, the Working Group will consider security, privacy, transparency, performance, and deployment properties, aiming to comparably meet the needs of today's applications that use CT-based PKIs with TLS. In particular the WG will deliver a design that can ensure that a misbehavior by a single party cannot compromise transparency for relying parties. The Working Group may consider how these mechanisms may apply to other PKIs or non-interactive protocols, but these will not be the primary use case and may ultimately have different requirements or limitations.
 
 The PLANTS Working Group's scope is to explore mechanisms for CAs and transparency ecosystems to certify key/identifier bindings in a publicly monitorable way. Alternate trust models and changes to how TLS uses the end-entity key are not in scope for the Working Group.