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

[Ryan Sleevi]

On Wed, Sep 9, 2020 at 3:33 PM Paul Walsh <paul at metacert.com> wrote:

>
> On Wed, Sep 9, 2020 at 12:08 PM Dimitris Zacharopoulos (HARICA) <
> 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.
>
>
> [PW] I’m sorry if I’m asking a specific question that has been answered
> already. I’m really hoping to learn more about this particular issue. Even
> if I get a response that’s not to my understanding or liking, I’ll simply
> digest it, and leave it at that :)
>
> Referring only to fields that browsers don’t use - are there any fields
> that have been empty, or populated incorrectly in the past, that resulted
> in a security problem for one or more organization?
>

Yes.


> If yes, is it possible to get a link to a news website or company blog
> where the security incident was announced? I’d also love to learn how those
> fields caused a problem if they’re not used by browsers.
>

Given that members of the Forum take umbrage at highlighting failures of
CAs to uphold the Baseline Requirements, I can only encourage you to
carefully read through https://wiki.mozilla.org/CA/Incident_Dashboard and
see the numerous incidents that have been caused.

However, you also need to carefully re-read my previous message; this
additional data limits automation, increases secondary dependencies that
harm improvements (and the list is 100% of every contentious deprecation
discussed in this Forum, from SHA-1 to lifetimes), and creates more
challenges for organizations. It creates couplings that have no technical
reason to exist other than convenience, and given that such convenience
actively harms browser users by limiting the ability to effectively improve
TLS within our products, that's a real problem.


> If a browser doesn’t need specific fields, can’t they just ignore them and
> allow other certificate consumers to use them?
>

No.

For example, a mobile carrier might want to consume certificates that
> contain one or two specific fields that browser vendors don’t use/trust,
> while ignoring the encryption aspect of the cert.
>

I'm not going to engage in hypotheticals here, because that's not
productive here for the OU discussion, other than the answer is what I
previously stated: use a different certificate.

There's a fundamental problem with your framing: "They want it, ergo it
must be good / we should allow it." There are many things I want, but it
would be harmful to myself, to others, and society at large if I just got
everything I wanted. It's the same with certificates. They're just a
container format. We would rightfully laugh at someone who tried to make a
Single API To Do Everything, where everything imaginable under the sun is
an optional parameter that can be sent. Why should we accept the same from
certificates?

If there are concrete use cases or needs for OU, let's discuss them, so we
can objectively evaluate whether the risk to agility, to security, and to
auditability are justified. But let's not engage in hypothetical "What ifs".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200909/7d845764/attachment-0001.html>