<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 3:16 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
Using arguments that are not relevant to the SCWG (SSL 3.0, RC4,
etc), which are not related to the actual Certificates used to
secure the TLS connection, which is what this SCWG is supposed to be
dealing with, is not very productive. </div></blockquote><div><br></div><div>It's key to understanding that plenty of people want insecure things.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Some Relying Parties find
useful information in the Certificates that are related to Identity.
The European Commission believes that Identity is important in
Website Authentication and several stakeholders of the public
Internet also support that. You seem to be dismissing that
completely, and instead reversing the questions without presenting
or discussing the problems you see with the existing situation. And
even when the WG agrees that the current situation can be
updated/improved, Google is pushing for removal of Identity
altogether, because if the OU is not required (which, like I said,
goes "hand-in-hand", extending the organizationName), then O is not
required, and then the same applies to L, ST, C.</div></blockquote><div><br></div><div>Indeed, and as shared in the browser responses in collaboration with the European Commission, there can be incredible value derived from eIDAS and it's model of providing legal assertions about identity.<br></div><div><br></div><div>However, and this is key, it's important to understand it doesn't need to be in TLS certificates. There are significant, insurmountable harms by placing it in TLS certificates, as we've seen from 15 years of experience. Browsers have been working with the Commission for 5 years now, and have had multiple informal meetings throughout, exploring these ideas and how to bridge the technological divide. I provided you links to some of the responses and designs ( see [1], [2]), that fundamentally explore why identity information within TLS certificates used by browsers is technologically unsound, and that the management of that identity information introduces substantial security and interoperability risks that can be entirely avoided through small adjustments. However, it's also worth noting that the interpretation that this information belongs in TLS is the result of ETSI ESI, not the Commission, and ETSI ESI has made a number of technical judgements that actively harm compatibility with the Web at large and browsers specifically. We discussed some of this at the Virtual F2F, about the need for our ETSI Liasons to more proactively collaborate, as WebTrust unquestionably does, so that we can avoid these unnecessary incompatibilities earlier, as we saw with PSD2, as we see by ETSI ignoring RFC 5280. That's a breakdown of our workmode, but that shouldn't be seen as proof that TLS is the "right" way.</div><div><br></div><div>[1] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-January/001555.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-January/001555.html</a></div><div>[2] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-August/002172.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-August/002172.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
At some point this Working Group and Browser Members need to address
the interoperability (and backwards compatibility) issues of the Web
PKI ecosystem because as you have pointed out in the past,
Publicly-Trusted Certificates must be compliant with non-Browser
implementations, despite them not being as secure as the current
modern Browsers that are represented in this WG (yes, the ones that
still support SSL 3.0, RC4, etc). If this WG produces Guidelines to
be consumed only by the Member Browsers, then why -for instance-
should we adhere strictly to the entirety of RFC 5280 and the size
limitations of the fields? We could create special Guidelines only
for the Member Browsers and possibly a distinct ecosystem with rules
directly coming from Member Browsers, and leave the current
Guidelines for non-Browser server TLS implementations. We could even
adopt a smaller number of Domain Validation methods that the Browser
Members consider more secure than others and use only those, shorter
reuse periods, etc.<br></div></blockquote><div><br></div><div>I agree! We can do these things! And, as you note, as a <b>distinct</b> PKI. There's absolutely no reason that the same certificate paths/set of root certificates would or should be used. Which is the point: the continued attempt to shoehorn everything that everyone "might" need in a single certificate is unsound technologically and actively harms user security.</div><div><br></div><div>The nice thing is we already have a place to start from, with existing roots operated for browsers and the existing structure of the Forum, which is for CAs and Browsers. If some CAs want to start a new set of Guidelines for not-TLS certificates, I think that'd be a welcome act, but it doesn't need to treat our existing guidelines as that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
IMHO, major changes to an existing and well-established ecosystem
like removal of subjectDN fields that may be used by Relying Parties
and Subscribers, must be fully justified because they may cause
disruption of solutions, for which the CAs have no idea whatsoever,
and they are not required to have any idea. </div></blockquote><div><br></div><div>This is a nonsensical argument. This ballot is very specifically about allowing a field in places where it's not presently allowed, and removing requirements for validation. The burden of proof absolutely rests with CAs. <b>Any</b> proposal for fields not directly used by browser applications absolutely has the burden of proof resting with CAs, precisely because this information is not used nor relevant to providing secure connections to users, and thus carries with it significant risk and unclear benefit. It is up to CAs to be able to articulate the use cases and benefits, because you're asking browsers to assume the risks and liabilities from it. Anything else is nonsense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>This was also pointed
out in a recent <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1651828#c8" target="_blank">comment
</a>in Bugzilla that caught my attention. From the moment the
Subscriber is aware of the terms and conditions and agrees with the
Subscriber Agreement and the rules that are attached with the
Certificate (for example, rules about revocation), the CA has no
obligation to ask how this Certificate will be used for TLS server
implementations.<br></div></blockquote><div><br></div><div>In an ideal world, I'd agree with you. However, the problem remains that CAs are using answers like "the customer uses this certificate in system X, and despite the Subscriber Agreement, finds it inconvenient to adhere to the Agreement". CAs unquestionably have an obligation to uphold the Baseline Requirements, and any failure to do so is a failure, by that CA, to behave in a trustworthy manner, since they very much commit to doing so.</div><div><br></div><div>However, that's about revocation, and you're overlooking the very real problems caused by adding unnecessary information, which is that it harms <b>issuance</b> agility and flexibility. If a browser only needs a domain name, and that information can be easily validated in O(seconds), then it absolutely is problematic when a CA begins adding information that takes O(days) to O(weeks) to validate. That harms issuance, <b>before</b> a user has accepted a certificate. Given that we need to be moving towards increased automation, and given that the only information <b>essential</b> is a domain name, every added bit of information introduces additional risks.</div></div></div>