[Servercert-wg] Displaying secure sites to Internet users

[Ryan Sleevi]

On Fri, Nov 15, 2019 at 3:09 PM Christian Heutger <ch at psw.net> wrote:

> Hi,
>
>
>
>    - This is an interesting essay, about a wide variety of topics
>    unrelated to certificates and the CA/Browser Forum, but it's unclear what
>    you believe the "problem statement" to be. I'm hopin you might be able
>    to refine it further?
>
>
>
> SSL/TLS certificates have been introduced from my point of view for
> encryption and authentification (two security factors based on information
> security definition, refer to ISO 27001).
>

While I'm quite familiar with ISO 27001, I don't think this dichotomy
exists like you suggest. SSL/TLS already provide robust authentication of a
domain name, which is how SSL/TLS is used on the Internet, and what the
CA/Browser Forum concerns itself with. This robust authentication, when
done following the Baseline Requirements and browser root programs, helps
ensure users can reliably connect to secure sites on the Internet.

So I'm not quite sure this is a problem statement, since we've clearly
"solved" this.


>
>    - In any event, hopefully that will encourage you to actually define
>    the problem to solve, which you can then discuss how your preferred
>    solution helps.
>
>
>
> Problem: Bring authentification (information security goal of
> authenticity) (back) to SSL/TLS ecosystem for deanomyzing the internet on
> users behalf not to fell victim of phishing, scaming and cybercrime. An
> additional factor is authentification therefor and a valid measurement are
> certificates issued by reliable third parties.
>

I must admit, I'm still not sure I understand. I can understand that, due
to CAs' presentations not being available yet, it may not be clear what
started this discussion.

However, it seems like the suggestion is "People fall victim to phishing,
and we should try to solve that", and the proposed solution is "The
Internet should not be anonymous". While your problem statement may be
uncontroversial, that doesn't mean the CA/Browser Forum is a good venue for
that, nor is the proposed solution necessarily desirable. However, it's
certainly something you could pose.

If the idea is that there should be a way to associate identity with domain
names, that's not too unreasonable to explore. However, there's no need to
do that with SSL/TLS certificates, which is the primary purpose of the
CA/Browser Forum. Even if the idea was to do it in SSL/TLS certificates, we
have the EV Guidelines to explore that. Unfortunately, we can see that the
EV Guidelines don't really provide a consistent, reliable form of identity.
When you look through https://wiki.mozilla.org/CA/Incident_Dashboard , you
can see rather remarkable incidents, from CAs responsible for the majority
of EV certificates. Failures in businessCategory, failures in serialNumber,
failures in locality and state names, jurisdiction data, the list goes on!
What's interesting about this is that a number of these issues are the
result of the EV Guidelines not placing sufficient normative restrictions,
leading different CAs to reach different conclusions on the acceptability
of certain practices.

It seems like if folks want to advocate that CAs are well-placed to discuss
identity in certificates, despite the rather damning evidence, then one of
the first steps to do would be to ensure that data validated according to
the EV Guidelines can be relied upon. That Incident Dashboard serves as a
good starting point - ideally, we should have a ballot for the EV
Guidelines for each of these issues. Unfortunately, I'm only aware of a
single CA working to improve this as an industry - DigiCert - and even
there, they've faced significant backlash from other CAs. That does seem
unfortunate, and does seem like identity in certificates may be a failed
experiment.

That said, we're fully supportive of any efforts that CAs would like to
lead to systemically address these issues. It seems like we've got a number
of opportunities here

   - Enumerated list of all the recognized jurisdictions a CA may consult
   for incorporating details (DigiCert has provided such a list)
   - Enumerated list of all the expected business identity information
   forms (that is, that appear in the serialNumber) for these jurisdictions.
   (DigiCert has suggested they will be proposing such a list)
   - Enumerated list of the different forms of business entities (e.g.
   Non-Governmental Entities appear to be a challenge for a number of CAs)
   - Enumerated list of all the locality information one can expect in a
   certificate

After all, the goal of such EV Guidelines is to ensure a consistent and
predictable result. For CAs who believe they're unaffected by the many
industry issues, they certainly seem well-placed to contribute ballots to
formalize best practices. And for the CAs that are affected by these
issues, formalizing their remediations seems extremely useful.

These efforts are nicely complementary to the efforts to improve audits and
disclosures. After all, the failure to detect these issues by auditors
should be of deep concern for the community, and looking to better capture
auditor expectations and disclosures seem like a further effort to improve
identity.

All of these things seem well-within our chartered scope. Discussions of
UI, of course, are completely outside the scope of our charter, and well
outside the expertise of members of this Forum. After all, we've seen folks
acknowledge that it requires product and UI expertise, and that's
inherently per-product. Just as we wouldn't expect Windows and macOS to
look identical, given how much their product experiences differ, it's
completely unrealistic to discuss trying to normalize UI.

Once we have reliable data in certificates, which we're clearly years away
from having in the existing ecosystem, then it might be useful to figure
out how to take advantage of that data in a way that helps users and
reduces phishing. This is likely best accomplished by moving this data out
of the SSL/TLS handshake, so that it better aligns with the Web security
model, doesn't harm the security (encryption or authentication) of HTTPS,
and helps explore how best to solve the problem(s) you seem to be concerned
about. But that's a few years away, and requires us first solve the
validation issues.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191115/d9bb6345/attachment.html>