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

Peter Bowen pzb at amzn.com
Wed Oct 12 00:26:37 UTC 2016


> On Oct 11, 2016, at 2:30 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Mon, Oct 10, 2016 at 8:34 PM, Peter Bowen via Public <public at cabforum.org> wrote:
> 
> > On Oct 10, 2016, at 5:31 PM, public at cabforum.org wrote:
> >
> > During the discussions about CT name redaction ([1], [2]), it became clear
> > that there is no formal policy regarding what actions a CA should take if a
> > domain owner approached the CA to get information about a certificate issued
> > by the CA for a domain owned by the domain owner. We'd like to start a
> > discussion to craft such a policy. Note that this is not specific to name
> > redaction. A domain owner might discover a non-redacted certificate in a CT
> > log or public web crawl, and if the owner doesn't recognize the certificate,
> > they should be able to get detailed information from the CA so that the
> > domain owner can determine if the cert was properly issued, and request
> > revocation if it was not.
> 
> Rick,
> 
> Before we discuss how we authenticate the domain registrant, I think need to discuss what a CA must do when so asked by a domain registrant.
> 
> As a straw man, I’m going to suggest that an authenticated domain registrant can do the following:
> 
> - Require revocation of a certificate containing a FQDN or Wildcard DN under their registered domain by providing the CA the issuer DN and serial number of the certificate
> 
> - Require revocation of all certificates containing a FQDN or Wildcard DN under their registered domain or a portion of the namespace under their registered domain
> 
> - Authorize the issuance of certificates containing a FQDN or Wildcard DN under their registered domain
> 
> - Require the CA to only allow certain named people or email addresses to authorize future issuance
> 
> The registrant cannot:
> 
> - Require the CA to provide a list of all certificates containing a FQDN or Wildcard DN under their registered domain
> 
> - Require the CA to provide details on the applicant/subscriber for a certificate containing a FQDN or Wildcard DN under their registered domain
> 
> - Require the CA to provide an unredacted version of a redacted certificate containing a FQDN or Wildcard DN under their registered domain
> 
> To come up with this list, I considered the situation where domain foo.example is registered to Alice (potentially using a proxy as the registrant).  Mallory is a nefarious individual and wants to bring harm to Alice or Alice’s organization.  Mallory manages to take over foo.example (either due to Alice letting it expire or via domain transfer fraud) and then proceeds to contact CAs to get info about foo.example and Alice.  What should a CA be required to release?
> 
> I think I'd disagree with most of the "cannot", but I agree, it's a slippery slope.
> 
> As we've seen during the discussion of CAA, several CAs feel that it's perfectly acceptable for the domain operator to be distinct from the certificate applicant - that is, that it's OK to issue certificates not necessarily approved by a central 'policy' team or other business controls. This has come up both in discussion of why CAA hard-fail is undesirable, and why "Letter from the CEO" is seen as an acceptable override.

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.

"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.

> If we accept this - that an organization may not necessarily be internally aware of the certificates they issue and their policies - then it would seem revocation may be a heavy handed response, especially for hypothetically redacted certs. Instead, it may be appropriate to disclose first - so that these teams can then internally collaborate and figure out of revocation is the right answer.
> 
> That is, if the risk you have to accept is that you could break some critical piece of your infrastructure if you revoke a redacted cert, simply because one team didn't talk to another team, internally, then I don't believe that's a good policy.
> 
> I use redaction here, but I think the same applies to "Revoke all certificates under this namespace"

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.

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?

Thanks,
Peter

[1] https://xkcd.com/177/ and https://en.wikipedia.org/wiki/Alice_and_Bob


More information about the Public mailing list