[cabfpub] Recourse for domain owners who discover unknown certificates issued to their domain

[Ryan Sleevi]

On Tue, Oct 11, 2016 at 5:26 PM, Peter Bowen <pzb at amzn.com> wrote:

>
> You are conflating two things here.  "it's perfectly acceptable for the
> domain operator to be distinct from the certificate applicant” - Yes.
> Akamai or Fastly (or any CDN) can apply for a certificate for a domain
> registered to one of their customers.  They can even get an OV certificate
> naming Akamai or Fastly as the organization with customer domain in the
> SAN.  We have covered this several times.
>

No, I wasn't conflating them, but perhaps I used imprecise terms that I
thought would have been clearer, due to the reference of CAA. In this case,
I'm talking about the DNS admin being distinct party from the certificate
applicant. That is, if we expect the DNS admin to always be the certificate
applicant, then the concerns with respect to CAA are unfounded. However, if
they're distinct parties (e.g. the marketing department vs the IT
department), as has been advanced as a reason to soft-fail CAA, then we
know that there is an internal need for the DNS team to know what the
marketing team is doing in a discoverable way.


> "OK to issue certificates not necessarily approved by a central 'policy'
> team or other business controls” - You will note that I specifically said
> that I think that CAs should be required to allow registrants to restrict
> who can authorize issuance.  Right now the BRs have, in section 3.2.5, a
> similar ability to restrict who can request (apply) for a given Applicant,
> but there is nothing for domain registrants.  I support hard-fail for CAA
> which, when combined with registrant dictated approval restrictions, would
> provide the ability to implement strong business controls.
>

Given that we don't have hard-fail for CAA (yet), I don't think this
problem is solved. It does suggest that this policy only becomes workable
with hard-fail with CAA, and with an appropriate policy that can dictate
either who can apply or *how* they can apply (e.g. to only allow
WHOIS-based contact, rather than file-based).


> I think you are missing a very reasonable course of action — the
> example.com registrant asks the CA to have the subscriber for the unknown
> certificate contact somebody at example.com.  In this manner the CA does not
> provide customer information to a third party without the customer’s
> consent but there is an opportunity to initiate communication to
> collaborate to see if revocation is the right answer.  If course if there
> is no contact then the registrant may request revocation.
>

It's only reasonable if it's required to be supported ;)


> Consider the malicious example where Bob[1] registers
> sultanofqumarblows.me via a proxy service.  The Qumari government
> prevails on the Montenegrin government to transfer the domain to the
> Qumaris.  Now they want to go after Bob so they contact the CA that issued
> the certificate for www.sultanofqumarblows.me and request applicant
> information.  Should the CA be required to disclose their customer
> information?
>

To be clear, I absolutely think there are a number of problems - both with
the disclosure of applicant information and domain - under adversarial
models. That's part of the problem with redaction, but also recourse -
determining who is authorized to know about a certificate.

I'm much less concerned with disclosing applicant information - I don't
think that's particularly germane to the use case (redaction) - but I agree
that, if we accept the threat model that those supporting redaction
advocate, this is problematic.

However, if we take the view, as I do, that all publicly-trusted
certificates should be publicly disclosed, then I don't think there's any
issue here with disclosure of the certificate, nor do I think there's any
need to disclose applicant information (at present)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161011/9e3cfa49/attachment-0003.html>