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

Ryan Sleevi sleevi at google.com
Wed Apr 26 22:39:25 UTC 2017

On Wed, Apr 26, 2017 at 6:05 PM, Kirk Hall via Public <public at cabforum.org>

> Gerv, I’m late to the discussion on this.  By can you start at the
> beginning, and explain why you believe DTPs should not be permitted to
> perform domain validation under any circumstances?

I support this approach, and believe domain validation is of critical
security relevance that it is vital that the organization whose audits are
being provided and examined do this correctly, and that the greatest risk
to the ecosystem has been caused by delegating this authority out.

This is clearly obvious not just in the Symantec case, but in the past
decade of issues with RAs (which are what we informally tend to call DTPs).

I’m not speaking from an Entrust use case, but I can imagine there could be
> cases where the CA has no one on staff who can read or interpret certain
> languages and alphabets (Russian Cyrillic, Greek, Arabic, Chinese,
> Japanese).  They want to do a WhoIs lookup, but can’t read or interpret
> what they see.  This could be a perfect situation for using a DTP for
> domain verification.

Or it would be indicative that using whois information in this manner
wouldn't be adequate, and other, more suitable levels of validation can be

I appreciate and support the desire to provide a robust, global service.
This can be met by hiring employees - and thus bearing the responsibility
for their activities - or using automated methods of validation that
provide greater assurance than relying on humans, which, as we know, have
human error.

> Clearly the work of all DTPs should be audited, and the DTP part of the
> audit should roll up somehow into the issuing CA’s audit.  I know that can
> be complex (and under current rules, may be hard for browsers to monitor
> and feel confident they understand the ENTIRE network of DTPs, etc. used by
> the CA under each root).  But it can be done.

On what basis do you believe that it can be done? From ample discussion and
review of the literature, I assert it cannot be done to Google's

> I’m not personally familiar with the current complexity of making sure all
> DTPs are covered by a CA’s audit.  But wouldn’t it make sense to spend time
> working on the audit completeness problem (which is important in any case)
> and not forbid use of DTPs for domain verification?

I appreciate that you're not familiar with the current complexity, and thus
may not understand the past year of efforts, even prior to the Symantec
incident, to better understand the scope of audits and complexity. I'm sure
you're at least somewhat familiar, due to the discussions by our WebTrust
TF members, of the even longer effort by the WebTrust TF.

I hope that the above message suitably demonstrates alternatives to the
scenarios that you (although not Entrust, nor so far any other member) are
concerned about, but I'm not sure if you appreciate the seriousness or
gravity of the concerns here. While I realize that may sound like "rushing
to snap decision", this is actually something that we've been looking at
closely for some time - again, even prior to the recent Symantec incident -
and certainly, for Google, feel this is the only appropriate way to reach
the level of security.

Given that you're not aware of Entrust being concerned about this, and no
other member has spoken up about this concern that you raise, do you feel
there are other concerns, perhaps ones that Entrust would have the
expertise and knowledge as to the reasoning and challenges, that might be
impacted by this? This would otherwise seem a simple and comprehensive fix
for an immediate issue, while still allowing time to continue to determine
whether there is a path to DTPs providing the necessary level of assurance
for the many, many concerns about validation. Or it may simply highlight
why, if DTPs are necessary to include organizational information, that it
might be that including organizational information is not possible with a
meaningful, publicly-audited level of assurance, and thus should not be
used by browsers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170426/46433f08/attachment-0003.html>

More information about the Public mailing list