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

LeaderTelecom B.V. info at leadertelecom.nl
Sat Feb 20 08:03:34 MST 2016


Dear Eric,

I mean this case:
[1]http://news.netcraft.com/archives/2013/10/07/phishers-using-cloudflare-for-ssl.html

If CDN will issue OV and EV for phishing web-sites then people will not trust
at all in "green bar". 

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.

19.02.2016 23:19 - Eric Mill wrote:  > 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
<[2]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: [3]public-bounces at cabforum.org
[mailto:[4]public-bounces at cabforum.org] On Behalf Of Adriano Santoni
Sent: Thursday, February 18, 2016 2:41 AM
To: [5]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: [6]public-bounces at cabforum.org
[[7]mailto: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 [[8]mailto:pzb at amzn.com]
Sent: Monday, February 15, 2016 2:49 PM
To: Doug Beattie <[9]doug.beattie at globalsign.com>
Cc: Dean Coclin <[10]Dean_Coclin at symantec.com>; CABFPub
<[11]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

[12]Public at cabforum.org

[13]https://cabforum.org/mailman/listinfo/public

   --
Adriano Santoni

_______________________________________________
Public mailing list
[14]Public at cabforum.org
[15]https://cabforum.org/mailman/listinfo/public
 

 --       [16]konklone.com | [17]@konklone



[1] http://news.netcraft.com/archives/2013/10/07/phishers-using-cloudflare-for-ssl.html
[2] mailto:jeremy.rowley at digicert.com
[3] mailto:public-bounces at cabforum.org
[4] mailto:public-bounces at cabforum.org
[5] mailto:public at cabforum.org
[6] mailto:public-bounces at cabforum.org
[7] mailto:public-bounces at cabforum.org
[8] mailto:pzb at amzn.com
[9] mailto:doug.beattie at globalsign.com
[10] mailto:Dean_Coclin at symantec.com
[11] mailto:public at cabforum.org
[12] mailto:Public at cabforum.org
[13] https://cabforum.org/mailman/listinfo/public
[14] mailto:Public at cabforum.org
[15] https://cabforum.org/mailman/listinfo/public
[16] https://konklone.com
[17] https://twitter.com/konklone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160220/2e13c8f3/attachment.html 


More information about the Public mailing list