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

[Ryan Sleevi]

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 and 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

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 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,
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
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 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

1) Can use a file-based method on 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 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 <
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
> 3.2.2.4 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 3.2.2.4 presents any problem we
> need to address.  To me, the much bigger issue beyond the narrow wording of
> BR 3.2.2.4 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]
> *Sent:* Thursday, November 19, 2015 5:19 PM
> *To:* Kirk Hall (RD-US)
> *Cc:* CABFPub (public at cabforum.org)
> *Subject:* Re: [cabfpub] New subject -- Applicant/Subscriber versus
> domain Registrant
>
>
>
> Kirk,
>
>
>
> 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 3.2.2.4 (as it is a
> common scenario).
>
>
>
> Contoso Ltd. registeres contoso.com.  All contacts in the whois data for
> contoso.com point to the Contoso Ltd corporate mailing address and all
> contact emails are ckent at contoso.com.
>
>
>
> Fabrikam, Inc. registeres fabrikam.com.  All contacts in the whois data
> for fabrikam.com point to the Fabrikam, Inc coporate mailing address and
> all contact emails are 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 and 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 and 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 3.2.2.4 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.
>
>
>
> Thanks,
>
> Peter
>
>
>
> (permission to repost is granted)
>
> TREND MICRO EMAIL NOTICE
> 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
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151120/b74bbf46/attachment-0001.html