[Servercert-wg] [EXTERNAL]Re: [cabf_validation] Underscores, DNSNames, and SRVNames

[Ryan Sleevi]

On Sat, Oct 27, 2018 at 12:38 AM Gordon Bock <gbock at microsoft.com> wrote:

> While we can certainly debate on how complete the corpus is for the CT
> logs, our objection is based on the > 600 organizations which are returned
> in existing telemetry which have “_”’s in the SANs.
>

Can you provide any concrete data for the discussion to support this claim?

For example, the criteria for determining "600 organizations", and how
that's been computed. Is it possible this data has included privately
trusted CAs? Or are you measuring the number of organizations you've
encountered which have reported certificates which have been evaluated
against a DNSName (not a SRVName) containing an underscore? There's lots of
ways to interpret that number.

The publicly-available and verifiable data puts that number at 497 distinct
subject O fields (including leading underscores), 109 excluding leading
underscores. If we go by the registerable domain (that is, considering the
public suffix list), this number represents 514 registerable domains
(including leading underscores) and 74 excluding. The difference here is
attributable to the many variations of O encodings - some organizations
operate several registerable domains, while some registerable domains are
represented by several organizations.

The benefit of using publicly-available information is we can make informed
decisions based on independently verifiable data. If there's an oversight
in the analysis Google has been performing, we'd love to correct it. If
there is data that CAs have, we'd love for them to share it, so that we can
be informed. Similarly, we'd love to help Microsoft understand if the
belief here is being driven by bad data or bad analysis.

At this point, we've sliced this data by distinct certificates,
organization groupings, issuer groupings, domains, registerable domains,
and more. We've compared it to past misissuances which have received
industry-wide condemnation and concern and in similar volume and impact.
The RFCs have remained unambiguous as to the expectation, and consistent in
their execution, across every case mentioned (A/AAAA, TXT, SRV). That such
strong advocates for not only ignoring, but encouraging, the practice is
disheartening to the future legitimacy of the activities we set out to do.


> While we agree that conformity is an issue, we believe it should addressed
> in a manner that minimizes impact to corporations, governments, and public
> institutions.  Using our CA’s to enforce conformity is a disruptive
> approach to conformity.  On this topic the practical costs outweighs the
> theoretical benefit.  These costs neither Microsoft nor Google would need
> to bear.  A less disruptive approach would be through browser enforcement.
> Many organizations who leverage “_”’s have likely operated for many, many
> years using systems that involve distributed “fat” clients that have
> nothing to do with a web browser.  In these cases there is a high cost of
> implementing this change.
>

Thanks. We'll have to agree to fundamentally disagree.

An approach to conformity or compliance that says non-compliance by CAs is
irrelevant unless and until browsers enforce is to ignore the purpose of
RFC 5280 (and its predecessors) to ensure a consistent and interoperable
experience (regardless of browsers). It equally ignores the historic
misfortune of RFC 5280 encouraging Postel's Law - which was to encourage
clients to be liberal in what they accept, on the expectation and belief
that CAs would be conservative in what they send. Clients that cannot rely
on CAs to not certify invalid certificates - or invalid names - simply puts
unnecessary burden and strain on the ecosystem, particularly  new
implementors. It ignores the significant cost born by multiple
organizations - Mozilla and Google included - have faced in trying to
develop more secure and robust systems, across the ecosystem - from the PKI
to the IDN to the Web Platform.

Root programs that approach compliance as 'client' issues rather than what
they fundamentally are - issues with the CA's failing to abide by the CA's
CP/CPS and the requirements we collaboratively work to set - undermines the
fundamental value proposition of the CA/Browser Forum. It speaks most
troubling to root programs approach to policy non-compliance - the matters
that browsers can neither detect nor enforce - as it suggests that any
non-compliance, technical or other, may be ignored, if the root program
doesn't think it's a big deal. That harms the ecosystem, and the trust in
that root program, rather substantially.

It equally speaks to the volume of issues we're having with audits, as it
serves to critically undermine them. During each layer of the stack, from
the CA, to the auditor, and now to the root program, each actor is being
empowered to independently make a decision about what sort of
non-compliance is appropriate to report on, let alone be concerned about.
An approach that says material and unambiguous non-compliance is a
non-issue is to encourage further suppression of errors, which we've seen
has substantially undermined faith in the CA ecosystem - from DigiNotar to
more recent CAs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181027/eea26ecb/attachment.html>