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

[Ryan Sleevi]

On Thu, Sep 10, 2020 at 12:55 PM Paul Walsh <paul at metacert.com> wrote:

> Hi Ryan,
>
> I tried to avoid posting a follow-up, but I had to correct your perception
> - I didn’t provide enough insight in my original message - my bad.
>
> My carrier/operator example isn’t a hypothetical - sorry for not making
> that clear. I can’t name names but some carriers want to implement identity
> verification for URLs inside SMS messages to combat fraud/phishing. They
> say that trying to block known threats with multiple vendors isn’t working
> well enough.
>

There's nothing inherently wrong with that proposal, and certainly, one of
the many places where identity information about a domain can potentially
be useful. However, the only caveat is that such use cases don't need to be
expressed within TLS itself. The example given previously, of serving a
certificate via a defined .well-known URL, could easily provide such
information, and even further allow carrier-defined policies (e.g.
broadcasting a particular URL via a particular carrier requires prior
agreement with that carrier). So I'm not dismissive at all of the value of
identity verification with URLs, but rather, highlighting that there's no
technical reason to use it in TLS (which itself opens up new risks, for
that use case)


> Due to how my company serves identity info (API instead of TLS), it's in
> my personal interest to find common ground with you. So I’m motivated to
> find security issues related to empty/incorrectly populated fields that are
> ignored by browsers. I just can’t get my head around how unused data has
> caused actual harm to browser users.
>
> I’ve read as much as I could on this topic thanks to your links. I found
> it easy to find issues related to fields that browsers use, but I couldn’t
> find any security issues related to fields that browsers do not use. I know
> you’re busy, but it would be really amazing if you could point me to just
> one specific issue so I can really see where you’re coming from.
>

The Chair of the Forum has, in their official capacity, expressed concerns
that sharing specific CA incidents, despite being publicly available with
the intent to help inform and improve the ecosystem, represent Code of
Conduct violations because they may embarrass a particular member company,
and apparently that is a higher priority than collective improvement.

However, I think this question is also framed poorly: there's ample
evidence that fields unrelated for TLS cause impact in complying with the
requirements for TLS, ranging from the aforementioned SHA-1 deprecation
(and browser-used certificates being used in non-browser use cases, like
payment terminals) to eIDAS (for example, a CA that misissued 100% of their
Qualified Certificates, which lead to revocation). You can equally find
ample discussion among revocation delays where the revocation delay was
caused by a customer using a certificate in an unrelated purpose or
application, and that the constraints of that application or purpose
leading to the Subscriber violating their Subscriber Agreement, and the CA
violating their CP/CPS in order to accommodate that Subscriber. Looking at
delayed revocations is fairly easy here.

Put differently, each use of a browser/OS-intended TLS certificate outside
of that browser/OS-intended use case is, inherently, a security risk,
because it affects the ability to comply with the security policies of that
browser/OS.  Using the example you cited above, should an organization be
required to use an OV/EV certificate, as implied by the proposal, then such
an organization would be rate-limited in how quickly they could replace a
certificate, thus posing security risk to end users under a myriad of
situations. Similarly, the inclusion of such information also creates
substantially more risk of misissuance, which can lead to revocation, which
then requires reissuance, all of which act to disrupt the ability for such
websites to serve TLS-protected connections, also a security risk. If an EV
certificate, such an organization would be prohibited from automation,
which thus discourages regular certificate rotation, and thus again,
increasing security risk.

Although there are dozens of examples of those principles at play, as
reported by CAs, the underlying principles remain and can easily be
discussed as such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200910/1374b481/attachment-0001.html>