[cabf_validation] [EXTERNAL]Re: Revision to OU requirements

[Dimitris Zacharopoulos (HARICA)]

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.

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.

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 
comment <https://bugzilla.mozilla.org/show_bug.cgi?id=1651828#c8>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.

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.



On 2020-09-09 10:01 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Sep 9, 2020 at 12:08 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>     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.
>
>
> Not by browsers. Which is precisely why it doesn't belong in the TLS 
> certificates used, by browsers, to connect to a server.
>
>     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.
>
>
> 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.
>
>     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.
>
>     Is this WG or this Subcommittee supposed to be aware of all the
>     use cases "out there" and comment on that?
>
>
> 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.
>
>     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.
>
>
> Then I encourage you to read the Baseline Requirements again, and 
> carefully read the sections this ballot proposes to remove.
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200910/61c6f6fc/attachment.html>