[cabfpub] [EXTERNAL] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 9:27 PM, Brown, Wendy (10421) <
wendy.brown at protiviti.com> wrote:

> Ryan –
>
> I wasn’t at the F2F so missed the entire discussion.  But I would also
> like to understand the rationale for totally banning DTP rather than fixing
> the audit issue.  If it is difficult to audit the DTP, is it any easier to
> audit the same functionality when done by  the CA or is it just obtaining
> the independent audit of the DTP that is problematic?
>

Wendy,

I'm uncertain what you mean by easier - are you asking for the auditor, the
CA, or the browser?

For the auditor, it's easier, because it's part of the same scope and
system of operations, and, if this clause is removed, there's only one
party capable of performing domain validation. The auditor of the CA will
not examine the audit report of the DTP, for example - that's the
responsibility of the CA - whereas if it's part of the CA's scope, the
auditor of the CA will be able to opine on the security and propriety of
the system.

For the CA, it's easier, because they no longer have to maintain audit
reports from DTPs. As the past 3 years have shown us, across the CA
industry, ingesting an audit report is more than simply checking a box. For
example, the scope needs to be carefully examined to ensure all critical
controls are in place. The CP/CPS need to be examined for consistency with
the CA's. A failure of a CA to do this critical functionality is no
different than a CA that signs an unconstrained sub-CA - derelict in its
duty of trust and responsibility. But more difficultly, the skill and
expertise required - of which browser members are only now beginning to
fully appreciate, despite reviewing quite literally hundreds of audit
reports a year - clearly suggests that such a security critical function is
too important to outsource. Much like the disclosure requirements that have
come from requiring sub-CAs be disclosed, we're starting to see much bigger
issues.

For the browser, it's easier. As I mentioned, the sheer number of audit
reports is staggering. But, as I also mentioned - reviewing all of these
for consistency is absolutely something the browser must do in order to
meet its security objectives. Outsourcing this to CAs is detrimental to
that - if we believed it was sufficient, we wouldn't have audits in the
first place, since we can just trust the CA. But as we also talked about at
the F2F, a DTP performing domain validation is spiritually equivalent to an
unconstrained sub-CA, if the browser only cares about DV certs. However,
unlikely a sub-CA, there's no means and method of technically
distinguishing these, and as a result, there's no awareness or visibility
into the problems or how to respond to them, nor anyway to objectively
evaluate the claims from a CA regarding it if there are issues.

So we need transparency, and we need completeness. As of yet, no one has
spoken out about the benefits of DTPs for domain validation, besides the
Enterprise RA case, which I think the intent should still be to generally
support.


> Also I want to be sure I understand the proposal, are enterprise
> validators still allowed as long as they are only validating domains
> subordinate to a domain owned by that enterprise?
>

That's the use case we don't want to break, yes, and why I mentioned to
Gerv he was (unintentionally) breaking it :) The fact that the CA validated
the Domain Namespace means that at least the basics 'should' have been
performed correctly (for example, CAA validation), and that the party
attesting to the subordinate domain is appropriately authorized to attest
for it.

Limiting it to this would be a significant improvement over allowing
arbitrary third-parties to attest for arbitrary domains, with the
unfortunate hope that a contractual "don't do that" would be meaningfully
sufficient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170426/899af840/attachment-0003.html>