<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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. 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.<br>
<br>
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>
<br>
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. This was also pointed
out in a recent <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1651828#c8">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>
<br>
I assume other CA Members will have more experience in this area and
may in fact ask from their Subscribers to report on how their
Certificates will be used and how the attributes are used, so I will
stop here and hopefully see some more feedback/opinions from other
Members on this topic.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 2020-09-09 10:01 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvaOVRdRkUZ244MsZoJncNY6i6yyqy_NZaHxJsXBJJR4ww@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 12:08
PM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true">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>
It's also unambiguously clear that parts in a TLS
Certificates that are not related to a Domain Name, are
not part of the "processing model used in TLS to validate
a domain name". You have been advocating that, for any
Identity Information included in TLS Certificates, yet
there are cases where this information is used.</div>
</blockquote>
<div><br>
</div>
<div>Not by browsers. Which is precisely why it doesn't belong
in the TLS certificates used, by browsers, to connect to a
server.</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> Just as some people find it useful to locate
organization information in a Domain Name (via the Domain
Name registries/registrars), they find it useful to locate
organization information in TLS Certificates. </div>
</blockquote>
<div><br>
</div>
<div>Sure, and some people find it useful to use SSL 3.0, or
use SHA-1, or use RC4. The measure of whether or not
something is a good idea is not whether it's "useful" in
some hypothetical model, especially when it actively causes
harm. This is precisely what my previous message was
addressing, so I would encourage re-reading it. There's a
night and day difference here between comparing WHOIS, which
was designed as an abstract text protocol, and a very
specific use of TLS, by browsers, to connect to servers. </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>OrganizationalUnitName just follows the
organizationName attribute, it's usually a sub-section.
You will find lots of cases where O=My company, OU=Sales
Department or O=University of Utopia, OU=School of
Medicine, OU=Department of Surgery.<br>
<br>
Is this WG or this Subcommittee supposed to be aware of
all the use cases "out there" and comment on that?</div>
</blockquote>
<div><br>
</div>
<div>Yes, absolutely, if you're proposing to put this
information in, you absolutely need to know why. We cannot
discuss in the abstract, nor is it reasonable to discuss
about "that's just the way we did things", especially when
so many things done have no basis in technical reality. It's
no different than arguing we should put IP addresses in the
dNSName, because that's what CAs did, so clearly, they must
have had a reason, and if they had a reason, it must have
been good. There's so much flawed about that argument that
it doesn't even bear dissecting.</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> To the best of my knowledge there is no requirement
(at least not yet) for CAs to be aware of how the issued
certificates will be used by Subscribers, or the use cases
they have in mind. CAs just bind Subscribers to a
Subscriber Agreement that includes obligations like
revocation in certain timelines, etc. <br>
</div>
</blockquote>
<div><br>
</div>
<div>Then I encourage you to read the Baseline Requirements
again, and carefully read the sections this ballot proposes
to remove.</div>
<div><br>
</div>
<div>As I mentioned in the previous message: the starting
discussion is going to be, has to be, and will continue to
be, "assume the OU is forbidden. Why should it be allowed?"
If that cannot be articulated in a way that demonstrates the
value and overcomes the harm, it's a non-starter, plain and
simple.</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>