Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SECOM Request for EV Treatment
274 views
Skip to first unread message
Kathleen Wilson
Aug 5, 2015, 5:52:26 PM8/5/15
to mozilla-dev-s...@lists.mozilla.org
SECOM has applied to enable EV treatment for the "Security Communication
RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419.
SECOM is a Japanese commercial CA that provides SSL and client
certificates for e-Government and participates in several projects for
financial institutions to ensure the secured on-line transactions.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8641274
Noteworthy points:
* Documents are in Japanese. Translations of some sections are attached
to the bug.
Document Repository: https://repository.secomtrust.net/SC-Root2/index.html
CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
non-EV SSL CP:
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf
SSL Verification Procedures:
https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
English Translations:
https://bug1096205.bugzilla.mozilla.org/attachment.cgi?id=8573613
* CA Hierarchy
This root certificate has subordinate CAs which sign end-entity
certificates for SSL, EV SSL, email (S/MIME), and code signing.
Intermediate CAs are available here:
https://www.secomtrust.net/service/pfw/apply/sr/3_2.html
https://www.secomtrust.net/service/pfw/apply/ev/3_2.html
There is only one (internally-operated) subordinate CA that can issue EV
certs, namely "SECOM Passport for Web EV 2.0 CA".
Externally-operated subCAs are not allowed to issue EV certs.
There is currently one externally-operated subCA, Fuji Xerox. SECOM is
migrating this subCA to be internally-operated by SECOM and be included
in SECOM's policy documentation and audit.
* All three trust bits are already enabled for this root certificate.
The request is to enable EV treatment.
** The procedure that SECOM follows to verify the domain owner is the
same for EV and non-EV SSL certificates. The only difference is that no
lawyer opinion letter is used for Non-EV SSL. Translations from section
4-2 of SECOM’s Verification Document describe the process by which Whois
is used to verify that the domain owner is the same as the certificate
subscriber company name.
** Translations from Security Communication RootCA Subordinate CA
Certificate Policy (SCRootCP1) and PfWEVCA‐CP
3.2 Initial identification and authentication
3.2.1 Method to prove possession of private key
It is proved that the applicant has the private key as follows.
Certificate Signing Request, "CSR" submitted by the applicant and verify
that the corresponding public key contained in it is signed with private
key. In addition, check the fingerprint of the CSR to identify the owner
of the public key.
3.2.2 Authentication of company
Secom authorize the authentication of the applicant company as follows.
By using the official documents from central or local government,
database provided by QIIS or QGIS, and another ways that the equal level
of authorization possible.
3.2.3 Authentication of individual
Secom authorize the authentication of the applicant individual as
follows. By using the official documents from central or local
government, database provided by QIIS or QGIS, and another ways that the
equal level of authorization possible.
3.2.4 Information of non verified certificate user
Not described.
3.2.5 Confirmation of the authority to apply
Secom confirm that the applicant has proper right to apply the
certificate by the section 3.2 or 3.3 on this CP. In the case if the
application is made by third party, we request to give us the letter of
attorney.
* The third party application means that other than the company using
the host name described on common name of the certificate that is
described on the section 3.1.1.
4.3.1 Procedures to issue certificate by CA
Secom issues the certificate and prepares the certificate download site
only available for the applicant. The applicant uses a client
certificate or one time password along with access key to reach the
download site.
** Notes from the discussion of the inclusion request
*** There are 2 types of organizations. One is the organization
registered in the QIIS, "Tokyo Shoko Research". The applicant
information is obtained from the reliable independent source. This is
much like an organizational credit reporting agency. Tokyo Shoko
Research (TSR) is a member of the D&B Worldwide Network since 2005.
http://www.tsr-net.co.jp/en/outline.html
*** Another type is the organization not registered in the QIIS, "Tokyo
Shoko Rearch". This time, Secom require the organization to submit
"Certificate of seal impression". "Certificate of seal impression" is
the official document issued by the local government and only available
for the representative of the organization. This is the proof of the
real existence of the organization and there is no identity theft.
This is commonly referred to as a "chop". It can be viewed as the same
thing as what was formerly required in the US for corporations before a
lot of the corporate-procedure streamlining went into effect, the
"embossed seal" which was only available to the corporate secretary.
This chop is used for a traditional tool of business contract in Japan.
The proof of the chop is referred as "Certificate of seal impression".
"Certificate of seal impression" is issued by the Legal Affairs Bureaus
of Ministry of Justice. This official document is issued and available
only to the representative of the organization. This means that
possessing this official document is the proof of the representative of
the applicant's organization and there is no identity theft.
*** In order to validate the autority of the representative, make a
phone call to the organization using the telephone number from the
reliable independent source above, and ask switchboard for transfer to
the applicant's representative.
For those organizations not registered in the QIIS..
In stead of getting the information ourselves from QIIS directly,
however we get the Certificate of seal impression that is equally or
more reliable information source from the Legal Affairs Bureaus of
Ministry of Justice. The certificate of seal impression is submitted to
us by the representative because of the only available for the
representative of the organization. Possessing this official document is
the proof of the representative of the applicant's organization. Its
watermarked surface of the official document makes us securely verify
the original one and no copy or fraud made for the document.
** Translations of Secom Passport for Web EV service verification
procedures
4-2 Verification of the domain owner
By using Whois gateway(NIC domain reference function), we verify the
applied company name on domain information (the contents included in
CommonName) and the applicant (if the domain name use consent form is
submitted, it is same as the domain owner).
The two points to check for exclusive right to use.
For example, the applied CN is "WWW.login.secom.co.jp"
(1) Applied company or company that exists in parents/child relation
with the applied company owns "secom.co.jp".
(2) Applied company or company that exists in parents/child relation
with the applied company owns "login.secom.co.jp".
In order to check for parents/child relation, we use QIIS or QGIS(EDINET).
If we cannot find it, we ask the applicant to change the owner as same
as the applicant company name for WHOIS.
If we cannot refer the owner at Whois gateway, ask the applicant for
registration.
JP domain: http://whois.jprs.jp/ COM, NET, ORG domain:
http://www.networksolutions.com/cgi-°©‐bin/whois/whois
4-2-1 For the domain owner is different from the applicant company In
order to verify the exclusive ownership, we check either document below
if the domain owner is third party.
Domain name use consent form
Lawyer opinion letter
Points to be checked on the lawyer opinion letter is below.
(1) It is described that the domain (secondary domain) is exclusively
owned by the applicant company. The domain name is described at item #5
on the lawyer opinion letter.
(2) The lawyer who wrote the lawyer opinion letter is really existing
that is checked with 6. Check for the existence of the lawyer for
supplementation.
** Translation from https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
check whether you are the owner of the domain.
If it ends with ".JP" - JPRS WHOIS (Japan Registry Services Co., Ltd.)
Other - InterNIC Whois Gateway (Network Solutions, Inc.)
And if it is in the old organization information, if there is a mistake
in the registration information of the domain, please change to the
correct information contact the domain management company.
If it is set the domain information in private, please publish the
domain information.
** Translation from
https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html
1. site content / operator confirmation
In SECOM Trust Systems, and because of the certificate to prove the
existence of the web site, will check and review
- The presence of the web site
- The existence of the organization that operates the web site
- Requesting organization information, certificate issuance destination
information (CSR information) and match of the organization that
operates the web site
2. Confirmation of application information / domain information / trade name
Confirmation of domain information
Will make sure the organization that owns the domain.
If a third party (other than the applicant organization) owns the
domain, we will submit the documents in order to confirm or being used
consent with respect to the use of the domain. In addition, will check
the existence of the organization.
** Translations of Mail Authentication Service Verification Procedure
provided by SECOM
6. procedure4. Certificate information
Verify for DN information
Whether or not there is a mistake on DN information.
- Not same for company name
- Spelling mistake
- Domain name mistake
- The certificate was issued with the same DN before except the case of
renewal or reissue.
- Authentication by sending and receiving email.
If it is not possible to send or receive the email, we verify the
applied email address by making phone call or by another ways to the
applicant company.
7. procedure5. Verification of the domain owner
By using Whois gateway(NIC domain reference function), we verify the
applied company name on domain information (the contents included in
CommonName) and the applicant (if the domain name use consent form is
submitted, it is same as the domain owner).
JP domain: http://whois.jprs.jp/
COM, NET, ORG domain: http://www.networksolutions.com/cgi-°©‐
bin/whois/whois
8. procedure6. Verification by phone call
By making phone call to applicant company and make sure that the
applicant belongs to the company and apply for the certificate.
* EV Policy OID: 1.2.392.200091.100.721.1
* Root Cert URL: https://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
* Test Website: https://pfwtest.secomtrust.net/
CRL: https://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
http://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/fullcrl.crl
CRL issuing frequency for subordinate end-entity certificates: 24 hours
From SECOM CA Service Passport for Web SR 2.0 Certificate Policy
(PfWSR2CA-CP.pdf), Section4.9.7: CRL is expired regardless of treatment,
every 24 hours
OCSP: http://ev2.ocsp.secomtrust.net/
* Audit: SECOM is audited annually by PricewaterhouseCoopers Aarata,
according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=1717&file=pdf
WebTrust BR: https://bugzilla.mozilla.org/attachment.cgi?id=8519802
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1717&file=pdf
This begins the discussion of the request from SECOM to enable EV
treatment for the "Security Communication RootCA2" root certificate that
is currently included in NSS.
At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.
Kathleen
RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419.
SECOM is a Japanese commercial CA that provides SSL and client
certificates for e-Government and participates in several projects for
financial institutions to ensure the secured on-line transactions.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8641274
Noteworthy points:
* Documents are in Japanese. Translations of some sections are attached
to the bug.
Document Repository: https://repository.secomtrust.net/SC-Root2/index.html
CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
non-EV SSL CP:
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf
SSL Verification Procedures:
https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
English Translations:
https://bug1096205.bugzilla.mozilla.org/attachment.cgi?id=8573613
* CA Hierarchy
This root certificate has subordinate CAs which sign end-entity
certificates for SSL, EV SSL, email (S/MIME), and code signing.
Intermediate CAs are available here:
https://www.secomtrust.net/service/pfw/apply/sr/3_2.html
https://www.secomtrust.net/service/pfw/apply/ev/3_2.html
There is only one (internally-operated) subordinate CA that can issue EV
certs, namely "SECOM Passport for Web EV 2.0 CA".
Externally-operated subCAs are not allowed to issue EV certs.
There is currently one externally-operated subCA, Fuji Xerox. SECOM is
migrating this subCA to be internally-operated by SECOM and be included
in SECOM's policy documentation and audit.
* All three trust bits are already enabled for this root certificate.
The request is to enable EV treatment.
** The procedure that SECOM follows to verify the domain owner is the
same for EV and non-EV SSL certificates. The only difference is that no
lawyer opinion letter is used for Non-EV SSL. Translations from section
4-2 of SECOM’s Verification Document describe the process by which Whois
is used to verify that the domain owner is the same as the certificate
subscriber company name.
** Translations from Security Communication RootCA Subordinate CA
Certificate Policy (SCRootCP1) and PfWEVCA‐CP
3.2 Initial identification and authentication
3.2.1 Method to prove possession of private key
It is proved that the applicant has the private key as follows.
Certificate Signing Request, "CSR" submitted by the applicant and verify
that the corresponding public key contained in it is signed with private
key. In addition, check the fingerprint of the CSR to identify the owner
of the public key.
3.2.2 Authentication of company
Secom authorize the authentication of the applicant company as follows.
By using the official documents from central or local government,
database provided by QIIS or QGIS, and another ways that the equal level
of authorization possible.
3.2.3 Authentication of individual
Secom authorize the authentication of the applicant individual as
follows. By using the official documents from central or local
government, database provided by QIIS or QGIS, and another ways that the
equal level of authorization possible.
3.2.4 Information of non verified certificate user
Not described.
3.2.5 Confirmation of the authority to apply
Secom confirm that the applicant has proper right to apply the
certificate by the section 3.2 or 3.3 on this CP. In the case if the
application is made by third party, we request to give us the letter of
attorney.
* The third party application means that other than the company using
the host name described on common name of the certificate that is
described on the section 3.1.1.
4.3.1 Procedures to issue certificate by CA
Secom issues the certificate and prepares the certificate download site
only available for the applicant. The applicant uses a client
certificate or one time password along with access key to reach the
download site.
** Notes from the discussion of the inclusion request
*** There are 2 types of organizations. One is the organization
registered in the QIIS, "Tokyo Shoko Research". The applicant
information is obtained from the reliable independent source. This is
much like an organizational credit reporting agency. Tokyo Shoko
Research (TSR) is a member of the D&B Worldwide Network since 2005.
http://www.tsr-net.co.jp/en/outline.html
*** Another type is the organization not registered in the QIIS, "Tokyo
Shoko Rearch". This time, Secom require the organization to submit
"Certificate of seal impression". "Certificate of seal impression" is
the official document issued by the local government and only available
for the representative of the organization. This is the proof of the
real existence of the organization and there is no identity theft.
This is commonly referred to as a "chop". It can be viewed as the same
thing as what was formerly required in the US for corporations before a
lot of the corporate-procedure streamlining went into effect, the
"embossed seal" which was only available to the corporate secretary.
This chop is used for a traditional tool of business contract in Japan.
The proof of the chop is referred as "Certificate of seal impression".
"Certificate of seal impression" is issued by the Legal Affairs Bureaus
of Ministry of Justice. This official document is issued and available
only to the representative of the organization. This means that
possessing this official document is the proof of the representative of
the applicant's organization and there is no identity theft.
*** In order to validate the autority of the representative, make a
phone call to the organization using the telephone number from the
reliable independent source above, and ask switchboard for transfer to
the applicant's representative.
For those organizations not registered in the QIIS..
In stead of getting the information ourselves from QIIS directly,
however we get the Certificate of seal impression that is equally or
more reliable information source from the Legal Affairs Bureaus of
Ministry of Justice. The certificate of seal impression is submitted to
us by the representative because of the only available for the
representative of the organization. Possessing this official document is
the proof of the representative of the applicant's organization. Its
watermarked surface of the official document makes us securely verify
the original one and no copy or fraud made for the document.
** Translations of Secom Passport for Web EV service verification
procedures
4-2 Verification of the domain owner
By using Whois gateway(NIC domain reference function), we verify the
applied company name on domain information (the contents included in
CommonName) and the applicant (if the domain name use consent form is
submitted, it is same as the domain owner).
The two points to check for exclusive right to use.
For example, the applied CN is "WWW.login.secom.co.jp"
(1) Applied company or company that exists in parents/child relation
with the applied company owns "secom.co.jp".
(2) Applied company or company that exists in parents/child relation
with the applied company owns "login.secom.co.jp".
In order to check for parents/child relation, we use QIIS or QGIS(EDINET).
If we cannot find it, we ask the applicant to change the owner as same
as the applicant company name for WHOIS.
If we cannot refer the owner at Whois gateway, ask the applicant for
registration.
JP domain: http://whois.jprs.jp/ COM, NET, ORG domain:
http://www.networksolutions.com/cgi-°©‐bin/whois/whois
4-2-1 For the domain owner is different from the applicant company In
order to verify the exclusive ownership, we check either document below
if the domain owner is third party.
Domain name use consent form
Lawyer opinion letter
Points to be checked on the lawyer opinion letter is below.
(1) It is described that the domain (secondary domain) is exclusively
owned by the applicant company. The domain name is described at item #5
on the lawyer opinion letter.
(2) The lawyer who wrote the lawyer opinion letter is really existing
that is checked with 6. Check for the existence of the lawyer for
supplementation.
** Translation from https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
check whether you are the owner of the domain.
If it ends with ".JP" - JPRS WHOIS (Japan Registry Services Co., Ltd.)
Other - InterNIC Whois Gateway (Network Solutions, Inc.)
And if it is in the old organization information, if there is a mistake
in the registration information of the domain, please change to the
correct information contact the domain management company.
If it is set the domain information in private, please publish the
domain information.
** Translation from
https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html
1. site content / operator confirmation
In SECOM Trust Systems, and because of the certificate to prove the
existence of the web site, will check and review
- The presence of the web site
- The existence of the organization that operates the web site
- Requesting organization information, certificate issuance destination
information (CSR information) and match of the organization that
operates the web site
2. Confirmation of application information / domain information / trade name
Confirmation of domain information
Will make sure the organization that owns the domain.
If a third party (other than the applicant organization) owns the
domain, we will submit the documents in order to confirm or being used
consent with respect to the use of the domain. In addition, will check
the existence of the organization.
** Translations of Mail Authentication Service Verification Procedure
provided by SECOM
6. procedure4. Certificate information
Verify for DN information
Whether or not there is a mistake on DN information.
- Not same for company name
- Spelling mistake
- Domain name mistake
- The certificate was issued with the same DN before except the case of
renewal or reissue.
- Authentication by sending and receiving email.
If it is not possible to send or receive the email, we verify the
applied email address by making phone call or by another ways to the
applicant company.
7. procedure5. Verification of the domain owner
By using Whois gateway(NIC domain reference function), we verify the
applied company name on domain information (the contents included in
CommonName) and the applicant (if the domain name use consent form is
submitted, it is same as the domain owner).
JP domain: http://whois.jprs.jp/
COM, NET, ORG domain: http://www.networksolutions.com/cgi-°©‐
bin/whois/whois
8. procedure6. Verification by phone call
By making phone call to applicant company and make sure that the
applicant belongs to the company and apply for the certificate.
* EV Policy OID: 1.2.392.200091.100.721.1
* Root Cert URL: https://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
* Test Website: https://pfwtest.secomtrust.net/
CRL: https://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
http://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/fullcrl.crl
CRL issuing frequency for subordinate end-entity certificates: 24 hours
From SECOM CA Service Passport for Web SR 2.0 Certificate Policy
(PfWSR2CA-CP.pdf), Section4.9.7: CRL is expired regardless of treatment,
every 24 hours
OCSP: http://ev2.ocsp.secomtrust.net/
* Audit: SECOM is audited annually by PricewaterhouseCoopers Aarata,
according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=1717&file=pdf
WebTrust BR: https://bugzilla.mozilla.org/attachment.cgi?id=8519802
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1717&file=pdf
This begins the discussion of the request from SECOM to enable EV
treatment for the "Security Communication RootCA2" root certificate that
is currently included in NSS.
At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.
Kathleen
h-k...@secom.co.jp
Aug 13, 2015, 11:42:06 PM8/13/15
to mozilla-dev-s...@lists.mozilla.org
2015年8月6日木曜日 6時52分26秒 UTC+9 Kathleen Wilson:
Thank you Kathleen-san,
Out most recent the WebTrust audit report is posted at the URL below.
https://cert.webtrust.org/ViewSeal?id=1907
Hisashi Kamo
Secom
Out most recent the WebTrust audit report is posted at the URL below.
https://cert.webtrust.org/ViewSeal?id=1907
Hisashi Kamo
Secom
Kathleen Wilson
Nov 9, 2015, 6:55:05 PM11/9/15
to mozilla-dev-s...@lists.mozilla.org
> most recent the WebTrust audit report is posted at the URL below.
> https://cert.webtrust.org/ViewSeal?id=1907
>
> The updated SECOM CP for Ryan-san's comment is attached to
> https://cert.webtrust.org/ViewSeal?id=1907
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
>
> CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302
>
> The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP.
> The corresponding section were made comprehensible by red characters.
I propose that we move forward with approving and implementing SECOM's
request to enable EV treatment for the the "Security Communication
RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419.
In parallel, I plan to continue to track the action item for SECOM to
update their CP/CPS documentation to address the concerns that have been
raised. I believe that Ryan Sleevi is also planning to review the full
translated CP, but I am confident that SECOM will be prompt to address
any further concerns that are raised.
I plan to track SECOM's status on updating their CP in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
Does anyone have objections or concerns about this?
Thanks,
Kathleen
Kathleen Wilson
Nov 11, 2015, 5:26:37 PM11/11/15
to mozilla-dev-s...@lists.mozilla.org
SECOM to enable EV treatment for the "Security Communication RootCA2"
root certificate.
I am now closing this discussion and will recommend approval in the bug.
In parallel, I will also track the action item to finish the review of
SECOM's translated CP/CPS and for SECOM to finish updating their CP/CPS
(based on that review).
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
Peter Kurrasch
Nov 13, 2015, 8:43:42 AM11/13/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Kathleen, is SECOM getting special treatment? I was wondering if there was some reason to move forward before a CA has everything in order? Will we be seeing more of this going forward?
Original Message
From: Kathleen Wilson
Sent: Wednesday, November 11, 2015 4:26 PM
On 11/9/15 3:54 PM, Kathleen Wilson wrote:
>
> I propose that we move forward with approving and implementing SECOM's
> request to enable EV treatment for the the "Security Communication
> RootCA2" root certificate that was included in NSS via Bugzilla Bug
> #527419.
>
> In parallel, I plan to continue to track the action item for SECOM to
> update their CP/CPS documentation to address the concerns that have been
> raised. I believe that Ryan Sleevi is also planning to review the full
> translated CP, but I am confident that SECOM will be prompt to address
> any further concerns that are raised.
>
> I plan to track SECOM's status on updating their CP in the bug.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
>
> Does anyone have objections or concerns about this?
>
> Thanks,
> Kathleen
>
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Original Message
From: Kathleen Wilson
Sent: Wednesday, November 11, 2015 4:26 PM
On 11/9/15 3:54 PM, Kathleen Wilson wrote:
>
> I propose that we move forward with approving and implementing SECOM's
> request to enable EV treatment for the the "Security Communication
> RootCA2" root certificate that was included in NSS via Bugzilla Bug
> #527419.
>
> In parallel, I plan to continue to track the action item for SECOM to
> update their CP/CPS documentation to address the concerns that have been
> raised. I believe that Ryan Sleevi is also planning to review the full
> translated CP, but I am confident that SECOM will be prompt to address
> any further concerns that are raised.
>
> I plan to track SECOM's status on updating their CP in the bug.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
>
> Does anyone have objections or concerns about this?
>
> Thanks,
> Kathleen
>
Thanks again to everyone who reviewed and commented on this request from
SECOM to enable EV treatment for the "Security Communication RootCA2"
root certificate.
I am now closing this discussion and will recommend approval in the bug.
In parallel, I will also track the action item to finish the review of
SECOM's translated CP/CPS and for SECOM to finish updating their CP/CPS
(based on that review).
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
_______________________________________________
SECOM to enable EV treatment for the "Security Communication RootCA2"
root certificate.
I am now closing this discussion and will recommend approval in the bug.
In parallel, I will also track the action item to finish the review of
SECOM's translated CP/CPS and for SECOM to finish updating their CP/CPS
(based on that review).
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Kathleen Wilson
Nov 13, 2015, 9:27:46 AM11/13/15
to mozilla-dev-s...@lists.mozilla.org
On 11/13/15 5:43 AM, Peter Kurrasch wrote:
> Kathleen, is SECOM getting special treatment? I was wondering if there was some reason to move forward before a CA has everything in order? Will we be seeing more of this going forward?
>
I thought everything was in order, except perhaps there might be a few
> Kathleen, is SECOM getting special treatment? I was wondering if there was some reason to move forward before a CA has everything in order? Will we be seeing more of this going forward?
>
more suggestions to updating their CPS that could be tracked in parallel
(i.e. not show stoppers). We have done that in the past, and Ryan had
sent me email saying that he might not be able to participate in the
inclusion review discussions for a while, so to go forward without him.
But as you can see in the bug I realized that was not quite the case
when I went to write the summary to recommend approval. So, in the bug I
clarified that SECOM needs to make further updates to their CP/CPS
before we can move forward.
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205#c28
So, it was not intentional.
However, I would like to get the root inclusion/update discussions
moving forward again -- those discussions have stalled out.
Kathleen
h-k...@secom.co.jp
Nov 20, 2015, 2:00:27 AM11/20/15
to mozilla-dev-s...@lists.mozilla.org
2015年11月13日金曜日 23時27分46秒 UTC+9 Kathleen Wilson:
Dear Kathleen-san,
The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla.
https://bugzilla.mozilla.org/attachment.cgi?id=8689921
Email address verification does not apply to this EV SSL CP/CPS.
The corresponding section were made comprehensible by blue characters.
Thank you for your consideration.
The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla.
https://bugzilla.mozilla.org/attachment.cgi?id=8689921
Email address verification does not apply to this EV SSL CP/CPS.
The corresponding section were made comprehensible by blue characters.
Thank you for your consideration.
Kathleen Wilson
Nov 24, 2015, 7:25:10 PM11/24/15
to mozilla-dev-s...@lists.mozilla.org
On 11/19/15 11:00 PM, h-k...@secom.co.jp wrote:
>
> Dear Kathleen-san,
>
> The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla.
> https://bugzilla.mozilla.org/attachment.cgi?id=8689921
> Email address verification does not apply to this EV SSL CP/CPS.
>
> The corresponding section were made comprehensible by blue characters.
>
> Thank you for your consideration.
>
Thank you, Kamo-san.
>
> Dear Kathleen-san,
>
> The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla.
> https://bugzilla.mozilla.org/attachment.cgi?id=8689921
> Email address verification does not apply to this EV SSL CP/CPS.
>
> The corresponding section were made comprehensible by blue characters.
>
> Thank you for your consideration.
>
All,
As requested, the CP has been updated to reflect what SECOM does in
regards to domain name validation. Note that this information was
already available on the SECOM website, but we asked that it also be
added to their CP.
Here is the text that was added to the CP:
~~
The authentication method is as follows:
1. Using the WHOIS registry service, SECOM Trust System verifies that
the relevant subscriber owns the domain to which the Certificate pertains.
2. Should the owner of the domain be different from the subscriber,
SECOM Trust Systems authenticates the domain by having the domain owner
submit to SECOM Trust Systems a document granting subscriber the
permission to use the domain or by sending a verification e-mail to the
e-mail address of the domain owner registered in the WHOIS registry service.
~~
If everyone is OK with this, then I will proceed with recommending
approval of this request to enable EV treatment for the "Security
Communication RootCA2" root certificate.
I will also track an action item to ensure that SECOM adds the updates
in the translated version of their CP back to the original CP.
Kathleen
Kathleen Wilson
Dec 1, 2015, 12:34:09 PM12/1/15
to mozilla-dev-s...@lists.mozilla.org
Thanks again to everyone who reviewed and commented on this request from
SECOM to enable EV treatment for the "Security Communication RootCA2"
root certificate.
I am now re-closing this discussion and will recommend approval in the
bug. In parallel, I will also track the action item for SECOM to update
their original CP according to the changes they drafted in the English
version.
Peter Kurrasch
Dec 2, 2015, 2:14:01 PM12/2/15
to mozilla-dev-s...@lists.mozilla.org
I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers?
Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
Original Message
From: Kathleen Wilson
Sent: Tuesday, December 1, 2015 11:34 AM
> Here is the text that was added to the CP:
> ~~
> The authentication method is as follows:
> 1. Using the WHOIS registry service, SECOM Trust System verifies that
> the relevant subscriber owns the domain to which the Certificate pertains.
> 2. Should the owner of the domain be different from the subscriber,
> SECOM Trust Systems authenticates the domain by having the domain owner
> submit to SECOM Trust Systems a document granting subscriber the
> permission to use the domain or by sending a verification e-mail to the
> e-mail address of the domain owner registered in the WHOIS registry
> service.
> ~~
>
> If everyone is OK with this, then I will proceed with recommending
> approval of this request to enable EV treatment for the "Security
> Communication RootCA2" root certificate.
>
> I will also track an action item to ensure that SECOM adds the updates
> in the translated version of their CP back to the original CP.
>
> Kathleen
>
root certificate.
I am now re-closing this discussion and will recommend approval in the
bug. In parallel, I will also track the action item for SECOM to update
their original CP according to the changes they drafted in the English
version.
Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
Original Message
From: Kathleen Wilson
> Here is the text that was added to the CP:
> ~~
> The authentication method is as follows:
> 1. Using the WHOIS registry service, SECOM Trust System verifies that
> the relevant subscriber owns the domain to which the Certificate pertains.
> 2. Should the owner of the domain be different from the subscriber,
> SECOM Trust Systems authenticates the domain by having the domain owner
> submit to SECOM Trust Systems a document granting subscriber the
> permission to use the domain or by sending a verification e-mail to the
> e-mail address of the domain owner registered in the WHOIS registry
> service.
> ~~
>
> If everyone is OK with this, then I will proceed with recommending
> approval of this request to enable EV treatment for the "Security
> Communication RootCA2" root certificate.
>
> I will also track an action item to ensure that SECOM adds the updates
> in the translated version of their CP back to the original CP.
>
> Kathleen
>
Thanks again to everyone who reviewed and commented on this request from
SECOM to enable EV treatment for the "Security Communication RootCA2"
root certificate.
I am now re-closing this discussion and will recommend approval in the
bug. In parallel, I will also track the action item for SECOM to update
their original CP according to the changes they drafted in the English
version.
Kathleen Wilson
Dec 2, 2015, 3:18:15 PM12/2/15
to mozilla-dev-s...@lists.mozilla.org
On 12/2/15 11:13 AM, Peter Kurrasch wrote:
> I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers?
>
> Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
>
> The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
>
Copied from the Baseline Requirements (note #2 and #4)...
> I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers?
>
> Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
>
> The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
>
~
3.2.2.4. Authorization by Domain Name Registrant
For each Fully‐Qualified Domain Name listed in a Certificate, the CA
SHALL confirm that, as of the date the Certificate was issued, the
Applicant (or the Applicant’s Parent Company, Subsidiary Company, or
Affiliate, collectively referred to as “Applicant” for the purposes of
this section) either is the Domain Name Registrant or has control over
the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with
the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an
address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the
contact information listed in the WHOIS record’s “registrant”,
“technical”, or “administrative” field;
4. Communicating with the Domain’s administrator using an email address
created by pre‐pending ‘admin’, ‘administrator’, ‘webmaster’,
‘hostmaster’, or ‘postmaster’ in the local part, followed by the
at‐sign (“@”), followed by the Domain Name, which may be formed by
pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN by
making an agreed‐upon change to information found on an online Web page
identified by a uniform resource identifier containing the FQDN; or
7. Using any other method of confirmation, provided that the CA
maintains documented evidence that the method of confirmation
establishes that the Applicant is the Domain Name Registrant or has
control over the FQDN to at least the same level of assurance as those
methods previously described.
Peter Kurrasch
Dec 9, 2015, 11:36:10 PM12/9/15
to mozilla-dev-s...@lists.mozilla.org
(changed the subject since we're not talking about SECOM anymore)
Thanks for the info, Kathleen. Originally my concern was mostly with domain registrant proxies (if that's the preferred term?) but after reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items listed under section 3.2.2.4 have problems but some are worse than others (and there probably is no ideal solution anyway).
I offer the following:
1) Item 4 is not only exploitable but in fact has already been exploited. I think the incident came up in this forum but if not I'll try to dig up an article. Either way, I suggest that the Mozilla policy be to specifically forbid this practice by CA's seeking inclusion in the trust store and that the CA policy docs state they will not use any "magic" email addresses. Of course I would encourage the CABF to remove this item from the BR, but Mozilla should take action on this regardless.
2) Item 6 should be forbidden as well. Demonstrating control over a website is not the same as having practical control over a domain. Seizing control over someone else's website can be a fairly straightforward process in some cases, so manipulating a web page proves only that it can be manipulated. Again my recommendation is for Mozilla to forbid the practice, for the CA policy documents to explicitly state that the method will not be used, and that the BR be updated in due time.
3) Both items 5 and 7 are entirely too ambiguous and open-ended. (I tried to find any specifications on what a domain authorization document must contain but didn't see it.) As written, I could declare ownership in a number of silly ways that a less scrupulous CA might just accept. I can appreciate that CA's might want and need flexibility in how they perform the verification, so it's important that CA's also document their verification procedures in some detail in their policy docs.
My recommendation is for Mozilla to require a detailed description of any custom procedures that a CA intends to use. The description would be included in the CP/CPS and would need to specify the contents to appear in evidentiary documentation as well as how that documentation is to be transmitted from the cert applicant to the cert issuer. The CABF should tighten up the language in the BR, but Mozilla could still impose a mandate in the interim. Also: how long is a CA expected to retain such documentation and in what form?
4) Using WHOIS data as spelled out in item 3 is probably the most reliable mechanism since it is probably the least likely (amongst the other methods in section 3.2.2.4) to be falsified. That doesn't mean it can't be falsified, of course. However, if we set that aside there is still the matter of dealing with registrant proxies. If such a proxy is used, the information in whois cannot be relied upon to validate that the cert applicant is the actual domain owner. So the question becomes: How does a CA know if the contact info in whois is for a proxy or the real registrant? I don't have a good answer for that which leaves me a little dissatisfied with item 3.
5) Items 1 and 2 seem like they are fairly trustworthy but are not without pitfalls, too. For example, do cert applicants necessarily want their domain name registrar knowing if/when they have requested a cert, and under which CA? Is a registrar necessarily trustworthy enough to validate domain ownership all on their own without ever contacting the actual registrant?
I assume there are perfectly valid situations where the registrar can or even must provide that validation, but I don't think a registrar should be trusted to make that decision under any and all circumstances. They probably can be trusted to have the correct contact info for the true owner-registrant but then what do you do if all they have is the proxy registrant's info? And how do I know that my registrar will not just give out my information to anyone who calls up posing as a cert issuer (i.e. be susceptible to social engineering)?
The only recommendation I have at this point is that CA's should stipulate under what conditions they will use method 1 for ownership validation. I would expect it to be limited to specific situations but I don't know.
The other subsections in 3.2.2 look like they might be problematic too, but I only really focused on 3.2.2.4.
Any thoughts? Did I overlook something?
| From: Kathleen Wilson Sent: Wednesday, December 2, 2015 2:18 PM |
On 12/2/15 11:13 AM, Peter Kurrasch wrote:
> I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers?
>
> Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
>
> The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
>
>
> Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain.
>
> The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly.
>
Jakob Bohm
Dec 10, 2015, 10:01:05 AM12/10/15
to mozilla-dev-s...@lists.mozilla.org
On 10/12/2015 05:36, Peter Kurrasch wrote:
> (changed the subject since we're not talking about SECOM anymore)
>
> Thanks for the info, Kathleen. Originally my concern was mostly with
> domain registrant proxies (if that's the preferred term?) but after
> reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items
> listed under section 3.2.2.4 have problems but some are worse than
> others (and there probably is no ideal solution anyway).
>
> I offer the following:
>
> 1) Item 4 is not only exploitable but in fact has already been
> exploited. I think the incident came up in this forum but if not I'll
> try to dig up an article. Either way, I suggest that the Mozilla policy
> be to specifically forbid this practice by CA's seeking inclusion in the
> trust store and that the CA policy docs state they will not use any
> "magic" email addresses. Of course I would encourage the CABF to remove
> this item from the BR, but Mozilla should take action on this regardless.
>
This is actually the most common way for "domain validated"
> (changed the subject since we're not talking about SECOM anymore)
>
> Thanks for the info, Kathleen. Originally my concern was mostly with
> domain registrant proxies (if that's the preferred term?) but after
> reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items
> listed under section 3.2.2.4 have problems but some are worse than
> others (and there probably is no ideal solution anyway).
>
> I offer the following:
>
> 1) Item 4 is not only exploitable but in fact has already been
> exploited. I think the incident came up in this forum but if not I'll
> try to dig up an article. Either way, I suggest that the Mozilla policy
> be to specifically forbid this practice by CA's seeking inclusion in the
> trust store and that the CA policy docs state they will not use any
> "magic" email addresses. Of course I would encourage the CABF to remove
> this item from the BR, but Mozilla should take action on this regardless.
>
certificates. It uses a standard defined point of contact that has a
reasonable chance of being done by a different computer system than the
one protected by a web server TLS certificate, thus reducing the chance
of a web server compromise escalating to obtaining a fraudulent
certificate for permanently hijacking that site.
>
> 2) Item 6 should be forbidden as well. Demonstrating control over a
> website is not the same as having practical control over a domain.
> Seizing control over someone else's website can be a fairly
> straightforward process in some cases, so manipulating a web page proves
> only that it can be manipulated. Again my recommendation is for Mozilla
> to forbid the practice, for the CA policy documents to explicitly state
> that the method will not be used, and that the BR be updated in due time.
>
webserver domains have e-mail servers handling them, which is why #6
(or a similar technique for DNS) is sometimes used.
>
> 3) Both items 5 and 7 are entirely too ambiguous and open-ended. (I
> tried to find any specifications on what a domain authorization document
> must contain but didn't see it.) As written, I could declare ownership
> in a number of silly ways that a less scrupulous CA might just accept. I
> can appreciate that CA's might want and need flexibility in how they
> perform the verification, so it's important that CA's also document
> their verification procedures in some detail in their policy docs.
>
but should be listed in the specific CPS, for example:
- The CA is itself the subject of the certificate
- Ultra high security procedures involving direct non-Internet contact
between the CA and the subject. For example Government CAs often uses
government internal identity checking procedures when issuing
certificates for Government entities.
- Regular high security procedures such as requiring the subject to
appear in person with specific kinds of identity proof combined with
checks against official records.
- A (Sub)CA issuing e-mail and client certificates to its employees.
- Previously validated CA customers logging on to a secure CA web
portal to request additonal certificates.
- Renewal via proof of possession of the prior certificate.
As for #5 a domain authorization document is often a message from the
WHOIS registrant of the domain that another party is allowed to request
the certificate.
Some common cases:
- The web page is hosted on a shared server and the hosting provider
wants to add the domain name as a SubjectAlternativeName to the
certificate that handles incoming https for all the domains hosted on
a given IP address. Here the verified domain owner issues a form
letter authorizing the hosting provider to make that request from
their chosen CA.
- The web page is held "in trust" for its true owner by a related party
(e.g. the domain may be registered in the name of an executive or
sister company yet the certificate is requested by the IT department
elsewhere in the legal structure of a big organization).
- The certificate requesting is done by an outsourced IT organization
and the actual owner issues a letter authorizing that outsourced IT
organization to request the certificate.
- The domain is registered via a proxy and the proxy then issues a
document allowing the true owner to request the certificate.
The CA must validate the originator of the message as thoroughly as it
would have a requestor-on-own-behalf and be equally thorough in
validating that the requestor is the entity named in the authorization
document. In practice the authorization document is required to refer
specifically to a single request via e.g. a date or some identifying number.
> My recommendation is for Mozilla to require a detailed description of
> any custom procedures that a CA intends to use. The description would
> be included in the CP/CPS and would need to specify the contents to
> appear in evidentiary documentation as well as how that documentation is
> to be transmitted from the cert applicant to the cert issuer. The CABF
> should tighten up the language in the BR, but Mozilla could still impose
> a mandate in the interim. Also: how long is a CA expected to retain such
> documentation and in what form?
>
>
> 4) Using WHOIS data as spelled out in item 3 is probably the most
> reliable mechanism since it is probably the least likely (amongst the
> other methods in section 3.2.2.4) to be falsified. That doesn't mean it
> can't be falsified, of course. However, if we set that aside there is
> still the matter of dealing with registrant proxies. If such a proxy is
> used, the information in whois cannot be relied upon to validate that
> the cert applicant is the actual domain owner. So the question becomes:
> How does a CA know if the contact info in whois is for a proxy or the
> real registrant? I don't have a good answer for that which leaves me a
> little dissatisfied with item 3.
>
mail" principle that prevents them from forwarding challenge messages
to the true owner. Hence the need for using the other items as
fallback.
>
> 5) Items 1 and 2 seem like they are fairly trustworthy but are not
> without pitfalls, too. For example, do cert applicants necessarily want
> their domain name registrar knowing if/when they have requested a cert,
> and under which CA? Is a registrar necessarily trustworthy enough to
> validate domain ownership all on their own without ever contacting the
> actual registrant?
>
CA's registration agent) is also the Registrar (or domain reseller) for
the domain. In other words these are cases of first hand knowledge but
possibly via a "sister company" relationship, e.g. between GoDaddy
domain registrations and GoDaddy CA . Or the previous relationship
between VeriSign Network Solutions and VeriSign the CA.
> I assume there are perfectly valid situations where the registrar can or
> even must provide that validation, but I don't think a registrar should
> be trusted to make that decision under any and all circumstances. They
> probably can be trusted to have the correct contact info for the true
> owner-registrant but then what do you do if all they have is the proxy
> registrant's info? And how do I know that my registrar will not just
> give out my information to anyone who calls up posing as a cert issuer
> (i.e. be susceptible to social engineering)?
>
> The only recommendation I have at this point is that CA's should
> stipulate under what conditions they will use method 1 for ownership
> validation. I would expect it to be limited to specific situations but I
> don't know.
>
>
> The other subsections in 3.2.2 look like they might be problematic too,
> but I only really focused on 3.2.2.4.
>
> Any thoughts? Did I overlook something?
>
>
> *Sent: *Wednesday, December 2, 2015 2:18 PM
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Peter Bowen
Feb 22, 2016, 12:21:08 PM2/22/16
to Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org
On Wed, Dec 9, 2015 at 8:36 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
> Thanks for the info, Kathleen. Originally my concern was mostly with
> domain registrant proxies (if that's the preferred term?) but after
> reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items
> listed under section 3.2.2.4 have problems but some are worse than others
> (and there probably is no ideal solution anyway).
>
> Thanks for the info, Kathleen. Originally my concern was mostly with
> domain registrant proxies (if that's the preferred term?) but after
> reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items
> listed under section 3.2.2.4 have problems but some are worse than others
> (and there probably is no ideal solution anyway).
>
> 4) Using WHOIS data as spelled out in item 3 is probably the most reliable
> mechanism since it is probably the least likely (amongst the other methods
> in section 3.2.2.4) to be falsified. That doesn't mean it can't be
> falsified, of course. However, if we set that aside there is still the
> matter of dealing with registrant proxies. If such a proxy is used, the
> information in whois cannot be relied upon to validate that the cert
> applicant is the actual domain owner.
>
> mechanism since it is probably the least likely (amongst the other methods
> in section 3.2.2.4) to be falsified. That doesn't mean it can't be
> falsified, of course. However, if we set that aside there is still the
> matter of dealing with registrant proxies. If such a proxy is used, the
> information in whois cannot be relied upon to validate that the cert
> applicant is the actual domain owner.
>
> Any thoughts? Did I overlook something?
>
Peter,
>
I think there is a key thing you overlooked. There is no requirement that
the certificate applicant is the domain owner. The Mozilla policy states
that the applicant can be authorized by the registrant. This is the case
of "proxy" registration; the registrant is the proxy entity.
The CA/Browser Forum is currently working to revise 3.2.2.4 to remove the
#7 option ("any other") and include new methods to allow the CA to
demonstrate they received authorization to issue the certificate. The
latest draft was posted to their public mailing list last week:
https://cabforum.org/pipermail/public/2016-February/006830.html
I'm happy to receive any comments directly if you are not a working group
member.
Thanks,
Peter
0 new messages