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

[Ryan Sleevi]

On Thu, Sep 10, 2020 at 3:16 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
> 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.
>

It's key to understanding that plenty of people want insecure things.


> 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.
>

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.

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.

[1]
https://archive.cabforum.org/pipermail/servercert-wg/2020-January/001555.html
[2]
https://archive.cabforum.org/pipermail/servercert-wg/2020-August/002172.html


> 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.
>

I agree! We can do these things! And, as you note, as a *distinct* 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.

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.


> 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 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.
*Any* 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.


> 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.
>

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.

However, that's about revocation, and you're overlooking the very real
problems caused by adding unnecessary information, which is that it harms
*issuance* 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, *before* a user has
accepted a certificate. Given that we need to be moving towards increased
automation, and given that the only information *essential* is a domain
name, every added bit of information introduces additional risks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200910/e69c84da/attachment-0001.html>