[cabfpub] FW: New subject -- Applicant/Subscriber versus domain Registrant

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Sat Nov 21 02:04:44 UTC 2015

Ryan – this is a good breakdown of the issue related to changing the introductory language to many of the domain validation methods as Peter initially suggested.

I can only start (for myself) with a simple statement (or OV and EV: I think the O field in the cert should be the organization that “owns” the website where the cert will be used, and I think that organization should (legally) be considered the Applicant and (later) the Subscriber for purposes of all the promises and warranties we must get from the Applicant/Subscriber according to the BRs.

I don’t care if an agent who has been hired and authorized by the Applicant/Subscriber, such as a web hosting company, does all the work to get the cert on the Applicant/Subscriber’s behalf – but I don’t want the web hosting company ever to be considered (legally) the “Applicant” or “Subscriber.”  The web hoster may have registered the domain for its customer and be listed as a contact email address in WhoIs, and so may actually click on an email to confirm the domain control for the Applicant as the agent of the Applicant, but the web hoster should never be considered to be the Applicant.  And I think for the most part a web hoster who clicks the CA’s Subscriber Agreement for the Applicant/Subscriber has legal authority to do so and can legally bind the Applicant/ Subscriber to the Subscriber Agreement terms and warranties.

I think our current BR language, including the definition of Applicant and Applicant Representative, encompasses this situation (agents acting on behalf of the website owner) pretty well now, so I don’t see a problem or a need for change for that situation.

Having said that, the kirk.example.com example below does raise some tough questions.  I would start by saying that only the domain example.com should be authenticated, and so the O field for kirk.example.com should say O= Example Corp. only.   However if there is a desire or commercial need for certs for kirk.example.com where the Applicant wants O=Kirk Enterprises LLC, then we can probably accommodate that by creating some new, more restrictive vetting rules in the BRs for authenticating at third level domains or higher (where the customer does not want the O field information to represent the owner of the SLDN).  And if there is a problem with our rules today on this point (for example, if the wrong party is listed in the O field for example.com because of use of a practical demonstration method), let’s work on that.  It may not be misrepresentation by the Applicant or a bad certificate if the SLDN owner has authorized it.

However, some responsibility or blame should extend to the owner of an SLDN if the owner allows a web hoster or other third party improperly to confirm ownership of the SLDN to a different party by using an email method or practical demonstration to misrepresent the owner to the issuing CA – the owner of the SLDN should lock down what the web hoster can do with the domain…  If the actual owner of the SLDN clicks a link or cooperates to show some other party as owner of the SLDN in a FQDN during domain authentication (or the web hoster does that), that’s potantially a misrepresentation to the CA that could lead to revocation of the cert if the CA finds out and does not receive a satisfactory explanation (such as “we have licensed the use of the domain to that other party, so it’s ok”).

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, November 20, 2015 5:07 PM
To: Kirk Hall (RD-US)
Cc: CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] FW: New subject -- Applicant/Subscriber versus domain Registrant

I can't help but feel this is an attempt to subtlely reintroduce the discussions we've had at length in the past - in Zurich and in Istanbul - regarding complexities of domain ownership and who the O field should represent. If you recall, this discussion was primarily held with respect to EV validation and wildcard certs, but as many of the participants of those discussions noted, the problems here extend both to OV/IV certs.

We can and should presume that DV, given it's lack of information about the Subscriber/Applicant beyond the domain portion, is out of scope.

These discussions primarily used appspot.com<http://appspot.com> and azurewebsites.net<http://azurewebsites.net> when we were discussing, mostly because Jody, Gerv and I were all discussing things.

A few selected threads/discussions to refresh memory:
- https://cabforum.org/pipermail/public/2015-May/005623.html
- https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#EV-Wildcards
- https://cabforum.org/2015/06/24/2015-06-24-face-to-face-meeting-35-minutes/ (search for EVWC)

To recap those discussions, consider the following example: kirk.example.com<http://kirk.example.com>

We discussed many of the parties that might be involved:
1) Kirk Hall, author of the content and logical operator of the kirk.example.com<http://kirk.example.com> origin
2) Example.com, provider of hosting services for Kirk Hall
3) CDN Corp, a CDN that provides SSL/TLS front-end services for example.com<http://example.com>, which does not offer them directly
4) Marketing Inc, the firm responsible for designing and maintaining the website on behalf of Kirk Hall
5) Payments LLC, the payment processing firm responsible for handling orders and financial details on kirk.example.com<http://kirk.example.com>
6) DNS Org, the company who operates the DNS services on behalf of Kirk Hall
7) Mail Corp, the organization who handles the MX records that kirk.example.com<http://kirk.example.com> responds to

It is worth noting that under both the existing and proposed validation methods, any of these parties (but one) are entitled to obtain a certificate for kirk.example.com<http://kirk.example.com>

1) Can use a file-based method on kirk.example.com<http://kirk.example.com>, or if control over DNS, add subrecords to establish validation
2) Can use validation based on the registerable domain portion (WHOIS)
3) Can use a file-based method on kirk.example.com<http://kirk.example.com> or a DNS based method
4) Can use a file-based method or equivalent
5) _Cannot_ obtain a certificate, unless they can get one of the other parties to make a suitable change on their behalf to satisfy a request
6) Can modify the DNS or respond to email (in the case of anonymized WHOIS that provides email forwarding services)
7) Can monitor/respond to emails as they come in

We know that CAs - and users - employ all of these methods today with publicly trusted CAs, and have for ... well, a long time. I don't believe the goal of the VWG was or is to somehow reform these - if that's the case, then it certainly hasn't been clearly communicated as such, and I think there might be louder opposition if so.

But to the problem at hand, what 'should' the information be presented as - whether this is O for OV or O for EV? As we've seen from the discussions on the calls, emails, and F2F, there isn't a clear consensus on there being 'one' right answer. We know that some CAs (and users) want the information presented to be who is operating the site, and we know that some CAs (and users) want it to be the person logically associated with the content. I don't think we'll resolve that here and now.

I think Peter's suggestions sound good, although I can fully understand and agree with your concerns that changing the language in localized parts requires thinking about how the BRs refer to things globally.

I think that the best way to resolve this is:
i) Recognize we don't have consensus yet for what the O field should present as
ii) Recognize that the VWG proposals provide many wonderful security benefits that we shouldn't let them get hungup on resolving i)
iii) Take a pass at the BRs, in their entirity, to find places where the language may be inconsistent with respect to the (unresolved) status quo, and update that language to reflect the present reality
iv) Longer term, if this is a topic members are passionate about, which I think we have evidence that some CAs are, work to build consensus as to those goals

Before we can do iii), we need some degree of agreement on i) and ii), and I should hope that should be easy to find, but do let me know if you disagree.

On Thu, Nov 19, 2015 at 5:36 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
[Reposting with permission, and responding]

If I understand your example and concern below, you are saying the one company Company 1 may end up getting certs (even with the name “Company 1” in the O field for OV and EV certs) for a domain that is actually registered in WhoIs to Company 2, and Company 1 and Company 2 have no common corporate ownership and are not affiliates.  Did I simplify the facts correctly?

And you are saying in that situation Company 1 does not “own or control” the domain belonging to Company 2, so we should change the wording in BR to recognize that in the domain validation process there can be cases where the Applicant does not actually “own or control” the domain, such as the situation above.  Did I (oversimplify) that correctly?

If I have understood your statement of the problem being addressed, I don’t think I agree with your conclusion.  If Company 1 is able to demonstrate practical “control” over the domain being validated by current validation methods 2-6 (or revised validation methods 2-9), then to me “ownership or control” has been demonstrated by Company 1, even if there is no obvious connection between the Applicant (Company 1) and the registered domain owner (Company 2).  If Company 1 can respond to one of the permitted email addresses, or can do a practical demonstration for the domain being validated, to me that is sufficient “control” to provide the cert.

If I have mischaracterized your comments, please excuse me.

I don’t think the current language in BR presents any problem we need to address.  To me, the much bigger issue beyond the narrow wording of BR is, who is the “Applicant”, who automatically becomes the “Subscriber” after acceptance by the CA through the rest of the BRs.  I think it must be the company that owns the website (and the cert) in question – in this case, Company 1 above - and not any agent or web hoster who is handling matters for Company 1 (and also not the WhoIs Registrant in this example, Company 2).

If we add any ambiguity or flexibility to who is (or may be) the Applicant, than all the other references to the Applicant and later to the Subscriber in the BRs become very unclear – in that case, who are we talking about, Company 1, the web hoster, or Company 2 – or yet someone else who has helped in getting the domain validation completed?  In fact, the Applicant and Subscriber agree to massive obligations to the CA and to the public under the rest of the BRs (and usually in the Subscriber Agreement between the Applicant/Subscriber and the CA), and we can’t afford any ambiguity about exactly who that is in all cases, even if the Applicant is helped by third parties as their agents, such as web hosters.

From: Peter Bowen [mailto:pzbowen at gmail.com<mailto:pzbowen at gmail.com>]
Sent: Thursday, November 19, 2015 5:19 PM
To: Kirk Hall (RD-US)
Cc: CABFPub (public at cabforum.org<mailto:public at cabforum.org>)
Subject: Re: [cabfpub] New subject -- Applicant/Subscriber versus domain Registrant


I think this has veered a little off course.  The scenario you describe is not the one I'm worried about.  Let me try to describe the scenario that I'm trying to ensure is clearly covered in the revised (as it is a common scenario).

Contoso Ltd. registeres contoso.com<http://contoso.com>.  All contacts in the whois data for contoso.com<http://contoso.com> point to the Contoso Ltd corporate mailing address and all contact emails are ckent at contoso.com<mailto:ckent at contoso.com>.

Fabrikam, Inc. registeres fabrikam.com<http://fabrikam.com>.  All contacts in the whois data for fabrikam.com<http://fabrikam.com> point to the Fabrikam, Inc coporate mailing address and all contact emails are bwayne at fabrikam.com<mailto:bwayne at fabrikam.com>

Example Service Corporation is a service provider located in Ames, Iowa in the United States.

Contoso, Fabrikam, and Example Service Co not affiliates of each other; they share no common ownership or control.

Example Service Corporation applies for a certificate with the Subject of "/C=US/ST=Iowa/L=Ames/O=Example Service Corporation" and two dNSNames in the subjectAltName extension: images.contoso.com<http://images.contoso.com> and blog.fabrikam.com<http://blog.fabrikam.com>.  The CA operator first performs verification of Example Service Corporation according to the BRs.  After this completing this verification, the CA sends emails to ckent at contoso.com<mailto:ckent at contoso.com> and bwayne at fabrikam.com<mailto:bwayne at fabrikam.com> to validate that Example Service Corporation has approval to get a certificate with the respective FQDNs.  After each responds, the CA issues the certificate.

I think that this is a fairly standard process and is compliant with the BRs today.  However the changes to suggest that Line E (option 3) must show the "Applicant’s domain ownership or control".  Some auditors or relying parties might suggest that simply having the Registrant respond to the email may not prove that the Applicant is the 'owner' of the domain nor that the Applicant has control of the FQDN.

I am proposing the changes to ensure that it is clear that an email to the registrant alone is sufficient to meet the requirements.


(permission to repost is granted)


The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.

Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151121/49fc1aac/attachment-0003.html>

More information about the Public mailing list