On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote: > (As always, wearing an individual hat here. In particular, I am *not* > speaking on behalf of the Chrome Root Program.)
Can we somehow inquire as to the Chrome Root Program's rationale for this change? What alternatives were considered? Was backwards compat considered in making this change? Is the program open to alternatives? The links you listed help, but they do not fully elucidate. I have questions below. Specifically the links you listed show that the concern is indeed applications with bad trust anchor defaults (i.e., the WebPKI roots) that use name forms other than dNSName (e.g., rfc822Name, for S/MIME), which matches my speculation elsewhere in this thread. What is not clear to me is why a slightly different policy would not be acceptable that also limits the breakage caused by this change. The slightly different policy I'm proposing is that the WebPKI CAs should not issue any certificates with any name forms other than dNSName, and that they must have either or both of clientAuth and serverAuth EKUs. The reasons I'd prefer such a policy are: - I don't see how PKIs for dNSName client certs would function differently than WebPKI CAs do for dNSName server certs! Therefore it follows that the two could and even should be the same PKIs. - There exist protocols that are fairly symmetric, such as SMTP (TURN) and others. I don't see what value anyone gets from making the entities playing the TLS client role in those should use different PKIs than from the same entities playing the TLS server role. - Such a policy would not break current uses of WebPKI-issued EE dNSName client certs. This relates to the previous item. > This draft is not the way to solve this problem. I agree, but I want to explore the policy change that motives it and potential alternative policy changes that mitigate the motivation for OP's I-D. > As for PKI hierarchies, the Web PKI, as curated by web clients, > authenticates web servers. All the policies and expectations around it, > from monitoring to domain validation to Certificate Transparency, are > maintained with web servers in mind. [...] I would say that "As for PKI hierarchies, the Web PKI, [...], authenticates machine FQDNs". More specifically I would say that the WebPKI does not certify any other name forms than dNSName. Do you disagree? Rephrased: is there any reason that the WebPKI cannot certify dNSName-only certificates for _clients_? What really differs between a certificate for dNSName foo.bar.example w/ serverAuth and dNSName foo.bar.example w/ clientAuth besides the EKUs? Is `foo.bar.example` not the same entity either way? If prior to this change the WebPKI could be said to not be able to reliably certify dNSName clientAuth certs then I would agree with the policy change. But if so I'd like to understand why the WebPKI could not reliably certify dNSName clientAuth certs. > That is not to say that backend services shouldn’t authenticate as TLS > clients with certificates. If a backend service needs to take the role of a > TLS client, a certificate from some PKI is a fine way to solve that. But > there is no reason for that to use the same PKI hierarchies as web server > authentication. [...] I really want to understand why the WebPKI cannot authenticate _clients_ w/ _only_ dNSName SANs. You are making the assertion, but I don't understand the rationale, and there must be one, and it might well become obvious when you lay it out. > [...]. You could use entirely private hierarchies, hierarchies > shared across a large class of applications (e.g. all of S/MIME), or > anything in between. As noted elsewhere in this thread, and in the > references you linked, this is the standard way you build applications with > TLS and X.509: I am not sure that a PKI for rfc822Name-named client entities would be appropriate for dNSName-named client entities. If anything I'm sure of the opposite. ISTM that for dNSName-named client entities there is no better way to identify and authenticate those entities to the issuing CAs than... the same mechanisms we use now for dNSName-named _server_ entities. If a PKI for dNSName-named client entities would work no differently than the WebPKI does for dNSName-named server entities then I want to understand why not use the WebPKI for dNSName-named client entities. My suspicion is that the Chrome Root Program's motivation for this change was indeed name forms other than dNSName ones, and that with the bathwater out went the baby. Nico -- _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
