[cabfpub] F2F Topic details: What should be represented in the "O" field?

[Doug Beattie]

Dean,

 

I don't think you're asking the right question: "Who can request a cert for
dean.example.com".  It's not who can request it, but more the relationship
between the Org field and the Domain in the CN or SAN, right?  In reality
you never know who is requesting the certificate, only what they put into
their request.

 

Today it's just domain validation that's needed to verify domains for OV
certs, no ownership:

- Verify Org is a company using an authorized repository

- Verify Applicant is authorized to represent the company 

- They can demonstrate domain control over the domain

 

There is no requirement to verify that the organization "owns" the domain
today, are you asking that we change the vetting rules for how domains are
added to OV certificates?

 

Even EV requirements let the company add domains to an EV cert by
demonstrating Domain Control using the same procedures as OV and DV (except
for item 7 is prohibited plus the signer approval step).  Are you
recommending we not allow companies to add domains to their certs with
domain control and that they must "own" the domain?

 

Doug

 

 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Dean Coclin
Sent: Thursday, February 4, 2016 5:26 PM
To: CABFPub <public at cabforum.org>
Subject: [cabfpub] F2F Topic details: What should be represented in the "O"
field?

 

As requested on today's call, please publish ahead of time any background
reading material for a topic which has your name next to it.

 

On Day 2 the subject topic is scheduled. Here is some background:

 

At the last F2F meeting we discussed what should go in the certificate "O"
field and what the definition of "applicant" should be. Ryan succinctly
summarized it and I transformed into the following example:

 

Who can request a cert for dean.example.com:

 

1.	Dean Coclin, author of the content and logical operator of the
dean.example.com origin
2.	Example.com, provider of hosting services for Dean Coclin
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 Dean Coclin
5.	Payments LLC, the payment processing firm responsible for handling
orders and financial details on dean.example.com
6.	DNS Org, the company who operates the DNS services on behalf of Dean
Coclin
7.	Mail Corp, the organization who handles the MX records that
dean.example.com responds to

 

At the last meeting, there was a debate between some who thought it should
be #1 and those that thought it should be whoever holds the private key. 

 

My position (and those of some others at the meeting) is that it should be
#1. The rationale is that this is what is of interest to relying parties. I
don't believe relying parties care who holds the private key nor who the
site's payment processor  or DNS operator are.  Relying parties want to know
who is responsible for the site content and, in case of problems, who they
should contact. 

 

I would like to open and continue a discussion of this topic (at the
meeting, not here)so that we can try and come to some consensus on this
issue. Of course, if you have a viewpoint that you'd like to elaborate ahead
of time, please feel free to do so.

 

Thanks

Dean

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160205/81582dd0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4289 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160205/81582dd0/attachment-0001.p7s>