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

Fri Feb 19 20:17:56 UTC 2016

> Using an OV or EV cert helps the consumer know exactly who they are
communicating with, which, in this case, is not the domain registrant.

A consumer communicating with a domain registrant's CloudFront distribution
or CloudFlare endpoint is communicating with the domain registrant. The CDN
is the domain registrant's authorized representative.

As a domain registrant, I can get a DV certificate via any endpoint I set
up using my powers as registrant. This can be a Raspberry Pi running in my
home, a colocated metal server in a data center I own, an EC2 virtual
server in "the cloud", or a CDN terminator I authorized. In all cases, it's
my choice as the domain registrant what tools I use to demonstrate to a CA
that I, the domain registrant, am in charge of the requested certificate's
associated private key.

-- Eric

On Thu, Feb 18, 2016 at 10:31 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> I completely disagree. In fact, I think only OV or EV should be permitted
> for CDNs  order to accurately indicate that the CDN is operating the domain
> name, not the domain name registrant.  Using an OV or EV cert helps the
> consumer know exactly who they are communicating with, which, in this case,
> is not the domain registrant.
>
>
>
> Jeremy
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Adriano Santoni
> *Sent:* Thursday, February 18, 2016 2:41 AM
> *To:* public at cabforum.org
> *Subject:* Re: [cabfpub] [Ticket#2016021801002046] F2F Topic details:
> What should be represented in the "O" field?
>
>
>
> I am also in favour of only allowing DV certificates for CDNs.
>
> Il 18/02/2016 10:12, LeaderTelecom B.V. ha scritto:
>
> Dear Wen-Cheng Wang,
>
> > One exception is the CDN SSL certificate, which is supposed to be a
> single certificate shared by many CDN customers which has their own domain
> names to be include the SAN field of the certificate. Since the CDN SSL
> certificate contains multiple domains owned by different
> organizations/entities, the value of the “O” field should be the official
> registered name of the CDN operator
>
> It can confuse end customers while they don't know who is CDN and who is
> not CDN. I suggest to use only DV-certificates for CDN.
>
>
> Please feel free to contact the undersigned any time with any questions
> or concerns that you may have.
>
> --
> Kind regards,
> Aleksei Ivanov
> Managing Director
> LeaderTelecom B.V.
>
> 18.02.2016 05:43 - 王文正 wrote:
>
> Chunghwa Telecom will not attend this F2F meeting, so here I would like to
> express our comments on this topic.
>
> I think that the value of the “O” field SHALL be the official registered
> name of the domain owner for OV and EV certificate since the owner is the
> only entity that is accountable and responsible for the certificate issued
> to its domain. Therefore, only the domain owner has the right to apply SSL
> certificates for its domains. If we allow OV and EV certificates to be
> issued without the notification of the domain owner, there might be some
> risk of man-in-the-middle attacks.
>
> One exception is the CDN SSL certificate, which is supposed to be a single
> certificate shared by many CDN customers which has their own domain names
> to be include the SAN field of the certificate. Since the CDN SSL
> certificate contains multiple domains owned by different
> organizations/entities, the value of the “O” field should be the official
> registered name of the CDN operator.
>
> In practice, the Applicant might not be the domain owner itself. However,
> in such kind of situation we always require that the Applicant to proof
> that the Domain Owner really delegate the Applicant to apply for SSL
> certificate on behalf of the owner. For example, a non-IT company might
> outsource the operation of its web site to an IT company and delegate the
> IT company to apply for SSL certificates on its behalf. In such situation,
> we always ask for the IT company to show the delegation of the non-IT
> company (the domain owner).
>
> For CDN SSL certificate, it is similar to the situation that the Domain
> Owners delegate the CDN operator to apply for SSL certificate for them.
> Therefore, we will always ask the CDN operator to show delegation of its
> CDN customers (the domain owners).
>
> For DV SSL certificate, there should be no “O” field. The reason is all
> the subject identity information present in the certificate must be
> validated by CA but the domain validation process does not actually
> validate whether it’s the domain owner who apply for the SSL certificate.
>
>
> Wen-Cheng Wang
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Dean Coclin
> *Sent:* Tuesday, February 16, 2016 8:25 AM
> *To:* Peter Bowen; Doug Beattie
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] F2F Topic details: What should be represented in
> the "O" field?
>
>
> And here is a summary of the discussions up to now on this topic. For our
> discussion Thursday. Peter will also be presenting remotely.
>
> Dean
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com <pzb at amzn.com>]
> *Sent:* Monday, February 15, 2016 2:49 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org
> >
> *Subject:* Re: [cabfpub] F2F Topic details: What should be represented in
> the "O" field?
>
>
>
> Doug,
>
>
>
> I think those are both relevant questions.  The relationship between
> applicant and FQDN and subject and FQDN are related by separate topics.
> See the attached summary of some of the dependencies.
>
>
>
>
>
> *本信件可能包含中華電信股份有限公司機密資訊**,**非指定之收件者**,**請勿蒐集、處理或利用本信件**內容**,**並請銷毀此信件**. *
> *如為指定收件者**,**應確實保護郵件中本公司之營業機密及個人資料**,**不得任意傳佈或揭露**,**並應自行確認本郵件之附檔與超連結之安全性*
> *,**以共同善盡資訊安全與個* *資保護責任**.*
> *Please be advised that this email message (including any attachments)
> contains confidential information and may be legally privileged. If you are
> not the intended recipient, please destroy this message and all attachments
> from your system and do not further collect, process, or use them. Chunghwa
> Telecom and all its subsidiaries and associated companies shall not be
> liable for the improper or incomplete transmission of the information
> contained in this email nor for any delay in its receipt or damage to your
> system. If you are the intended recipient, please protect the confidential
> and/or personal information contained in this email with due care. Any
> unauthorized use, disclosure or distribution of this message in whole or in
> part is strictly prohibited. Also, please self-inspect attachments and
> hyperlinks contained in this email to ensure the information security and
> to protect personal information.*
>
>
>
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org
>
> https://cabforum.org/mailman/listinfo/public
>
>
>
> --
> *Adriano Santoni*
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160219/a482a323/attachment-0003.html>