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

LeaderTelecom B.V. info at leadertelecom.nl
Thu Feb 18 02:12:30 MST 2016


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] 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 [[1]mailto:pzb at amzn.com]
Sent: Monday, February 15, 2016 2:49 PM
To: Doug Beattie <[2]doug.beattie at globalsign.com>
Cc: Dean Coclin <[3]Dean_Coclin at symantec.com>; CABFPub
<[4]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.


[1] mailto:pzb at amzn.com
[2] mailto:doug.beattie at globalsign.com
[3] mailto:Dean_Coclin at symantec.com
[4] mailto:public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160218/66d2a080/attachment-0001.html 


More information about the Public mailing list