SECOM Root Inclusion Request
Kathleen Wilson
certificate, and turn on all three trust bits.
SECOM Trust Systems is a Japanese commercial CA that provides SSL and
client certificates for e-Government and participated several projects
for financial institutions to ensure the secured on-line transactions.
SECOM provides information security services, including authentication
and secure data center management services, as well as safety
confirmation services, which assist companies in the event of a
large-scale disaster.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=527419
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=540510
Noteworthy points:
* Cert Download URL:
https://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
* The CP/CPS documents are provided in Japanese. English translations of
certain sections are provided in the Information Gathering Document.
Root CA Certification Procedures for Operation:
https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
Subordinate CA Certificate Policy:
https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
CA Service Passport for Web SR 2.0 Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf
CA Passport for Web EV Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
EV Verification Document:
https://bugzilla.mozilla.org/attachment.cgi?id=451885
CA Passport for Member 20 PUB Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfm20pub/PfM20PUB-CP.pdf
* This is the SHA256 version of the �Security Communication RootCA1�
(SHA1) root certificate that is currently in NSS. It will have separate
intermediate CAs for signing certificates for SSL, EV SSL, email, and
code signing.
* The request is to enable all three trust bits. Note that EV-treatment
is not requested at this time.
* From SECOM: The procedure we verify of domain owner is same for EV and
Non-EV SSL. The only difference is that no lawyer opinion letter is used
for Non-EV SSL.
** Translations of sections of PfWEVCA-CP:
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.
** Translations of sections of EV Verification Document:
2.3 procedure3. Physical existence of the applicant
The below is the procedures to verify the physical existence of the
applicant.
(1) Current address is same with the QIIS/ QGIS and the one on the
application.
QIIS/QGIS(EDINET(https://info.edinet.go.jp/EdiHtml/main.htm))
(2) If we cannot verify by (1), RA or operation manager visits the
current address and verify the physical existence.
(3) If we cannot verify by (1) or (2), we verify by lawyer opinion
letter. We verify: (a) The address for the current physical existence on
the letter. (b) The real existence of the lawyer who wrote the letter.
2.4 procedure 4. Domain/ CSR verification
4-1. The contents of (O) for CSR
4-1-1. Registered corporation
We verify the (O) is same as the financial statements publicly available
on the Web site.
If the financial statements is not available, it is verified by QIIS or
QGIS.
If it is not verified by the above, it is verified by certificate of
incorporation or lawyer opinion letter.
4-1-2. Government ministries and agencies and organization in
country/local public entity
We verify the (O) is same as QIIS, QGIS and get the screen capture.
If it is not verified by QIIS, QGIS, it should be roman alphabet of
Hepburn system.
For example, Yokohama city => Yokohamashi
Government and municipal offices => Kankocho
4-1-3. University/ National and public high school
We verify the (O) is same as QIIS, QGIS and get the screen capture.
If it is not verified by QIIS, QGIS, it should be roman alphabet of
Hepburn system.
For example, Tokyo university => Tokyo daigaku
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
Other than the above: http://www.uninett.no/navn/domreg.html
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.
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
Other than the above: http://www.uninett.no/navn/domreg.html
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: Not requesting EV at this time
* Test Website: https://scrootca2test.secomtrust.net
* CRL: https://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
** From PfWSR2CA-CP.pdf Section4.9.7: CRL is expired regardless of
treatment, every 24 hours
* OCSP: Not yet provided in this new hierarchy
* Audit: The 2010 audit was performed by PricewaterhouseCoopers Aarata
according to the WebTrust CA criteria, and is posted on the webtrust.org
website, https://cert.webtrust.org/ViewSeal?id=1087. The 2011 audit is
currently in progress.
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* None noted.
* SSL certs are OV or EV. The maximum validity for OV SSL certs is 5
years. The maximum validity for EV SSL certs is 2 years.
This begins the discussion of the request from SECOM to add the
�Security Communication RootCA2� root certificate, and turn on all three
trust bits. At the conclusion of this discussion, I will provide a
summary of issues noted and action items. If there are no outstanding
issues, then this request can be approved. If there are outstanding
issues or action items, then an additional discussion may be needed as
follow-up.
Kathleen
Kathleen Wilson
> SECOM has applied to add the �Security Communication RootCA2� root
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
Would at least two people please review and comment on this root
inclusion request from SECOM?
Kathleen
Kathleen Wilson
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
> * This is the SHA256 version of the “Security Communication RootCA1” (SHA1) root certificate that is currently in NSS. It will have separate intermediate CAs for signing certificates for SSL, EV SSL, email, and code signing.
Since no one has commented on this, perhaps there are no concerns
regarding this request from SECOM to add a newer version of a root cert
that is already in NSS.
Shall I proceed with the approval phase of this request?
Kathleen
Eddy Nigg
>
> Since no one has commented on this, perhaps there are no concerns
> regarding this request from SECOM to add a newer version of a root
> cert that is already in NSS.
>
> Shall I proceed with the approval phase of this request?
>
Yes, I have never heard of any issue with them and this is a roll-over
of an existing root. We might skip reviews or limit it for such
re-hashed roots. Re-hashing to a stronger hash is in the interest of the
parties and the root is already there in any case.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Jeremy Rowley
1) Their typical CPS doesn't require an out-of-bands verification of the
organization's existence. Instead they require that the applicant submit
"information that shows the existence of the organization". This practices
doesn't comply with Mozilla's revised policy which requires that the
information be obtained from an independent source of information or an
alternative communication channel.
2) Their CP doesn't state how they validate the authority of the applicant's
representative. This should also be an independent source of information or
an alternative communication channel.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, July 11, 2011 4:34 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: SECOM Root Inclusion Request
On 6/20/11 10:05 AM, Kathleen Wilson wrote:
> SECOM has applied to add the "Security Communication RootCA2" root
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
<snip>
> * This is the SHA256 version of the "Security Communication RootCA1"
(SHA1) root certificate that is currently in NSS. It will have separate
intermediate CAs for signing certificates for SSL, EV SSL, email, and code
signing.
Since no one has commented on this, perhaps there are no concerns
regarding this request from SECOM to add a newer version of a root cert
that is already in NSS.
Shall I proceed with the approval phase of this request?
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Jeremy Rowley
applicant representative to the applicant organization. This verification
is required under the updated Mozilla policy.
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, July 11, 2011 4:34 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: SECOM Root Inclusion Request
On 6/20/11 10:05 AM, Kathleen Wilson wrote:
> SECOM has applied to add the "Security Communication RootCA2" root
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
<snip>
> * This is the SHA256 version of the "Security Communication RootCA1"
(SHA1) root certificate that is currently in NSS. It will have separate
intermediate CAs for signing certificates for SSL, EV SSL, email, and code
signing.
Since no one has commented on this, perhaps there are no concerns
Carsten.D...@t-systems.com
I've got a simple -hopefully not silly- question just for my general understanding:
Due to the documentation provided "SECOM Passport for Web EV CA2" is not a Root-CA, although the CA Hirachy diagram says that it is cross-signed by "Security Communication EV RootCA2" (which is the one to be embedded).
As "SECOM Passport for Web EV CA2" is not up to speed so far, why is it be cross-signed in this case?
Thanks for any helpful clarification,
Kind regards
Carsten
-----Ursprüngliche Nachricht-----
Message: 2
Date: Mon, 11 Jul 2011 15:33:37 -0700
From: Kathleen Wilson <kathle...@yahoo.com>
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: SECOM Root Inclusion Request
Message-ID: <HM2dnXjX-JHf54bT...@mozilla.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 6/20/11 10:05 AM, Kathleen Wilson wrote:
> SECOM has applied to add the ?Security Communication RootCA2? root
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
<snip>
> * This is the SHA256 version of the ?Security Communication RootCA1? (SHA1) root certificate that is currently in NSS. It will have separate intermediate CAs for signing certificates for SSL, EV SSL, email, and code signing.
Hisashi Kamo
"SECOM Passport for Web EV CA2" is Subordinate CA.
The certificate issued from Security Communication EV RootCA2 to SECOM
Passport for Web EV CA2 is "Subordinate CA Certificate".
On the CA Hirarchy diagram, it is described as "Cross sign" should be
"Subordinate CA Certificate".
I applogize you if you confused at the description as "Cross sign".
Best regards,
Hisashi Kamo
<Carsten.D...@t-systems.com> wrote in message
news:mailman.2527.1310469973....@lists.mozilla.org...
加毛 寿
-----------------------------------------------------
Dear Carsten-san,
"SECOM Passport for Web EV CA2" is Subordinate CA.
The certificate issued from Security Communication EV RootCA2 to SECOM Passport for Web EV CA2 is "Subordinate CA Certificate".
On the CA Hirarchy diagram, it is described as "Cross sign" should be "Subordinate CA Certificate".
I applogize you if you confused at the description as "Cross sign".
Best regards,
Hisashi Kamo
<Carsten.D...@t-systems.com> wrote in message news:<mailman.2527.1310469973....@lists.mozilla.org>...
@All,
I've got a simple -hopefully not silly- question just for my general understanding:
Due to the documentation provided "SECOM Passport for Web EV CA2" is not a Root-CA, although the CA Hirachy diagram says that it is cross-signed by "Security Communication EV RootCA2" (which is the one to be embedded).
As "SECOM Passport for Web EV CA2" is not up to speed so far, why is it be cross-signed in this case?
Thanks for any helpful clarification,
Kind regards
Carsten
-----Ursprungliche Nachricht-----
Kathleen
----------
Hisashi Kamo
Thank you for the comments.
Let me answers below.
1)
There are 2types of organizations.
One is the organization registered in the QIIS, "Tokyo Shoko Research".
The applicant information is obtained from the reliable independent source.
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.
2)
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 1), and ask switchboard for transfer to the applicant's
representative.
Best regards,
Hisashi Kamo
"Jeremy Rowley" <jeremy...@digicert.com> wrote in message
news:mailman.2478.1310424724....@lists.mozilla.org...
Hisashi Kamo
Thank you for your comment.
The answer is below.
Same as the SSL certiifcate, making a phone call to the real existence
organization using the reliable independent source and ask switchboard for
transfer to the applicant's representative.
Best regards,
Hisashi Kamo
"Jeremy Rowley" <jeremy...@digicert.com> wrote in message
news:mailman.2479.1310424909....@lists.mozilla.org...
Kyle Hamilton
Many cultures write family names first, and I mean no disrespect.
On Thu, Jul 14, 2011 at 10:19 PM, Hisashi Kamo <h-k...@secom.co.jp> wrote:
>
> 1)
> There are 2types of organizations.
> One is the organization registered in the QIIS, "Tokyo Shoko Research".
> The applicant information is obtained from the reliable independent source.
I understand that this is much like an organizational credit reporting agency?
> 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.
I believe that 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.
The 'certificate of seal impression': Is it possible for any entity
other than the organization to obtain a copy of the impression to
compare against? Is it possible to send the certificate of
registration to the issuing local government for authentication?
A separate statement with an original (not photocopied or otherwise
reproduced) seal from the organization requesting CA service might be
useful.
> 2)
> 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 1), and ask switchboard for transfer to the applicant's
> representative.
Out-of-band verification of authority to use the organization's name,
utilizing authoritative information (i.e., contact information from
something much like Dun & Bradstreet)? I perceive this as acceptable.
However, for those organizations not registered in the QIIS, I cannot
perceive this as an effective issuance control (there is no other
reliable independent source described).
If I am misunderstanding, please would you correct me?
-Kyle H
Hisashi Kamo
Thank you for your concern about how you call me.
I do not care, both are all right.
Japanese people usually call family name, but let me call you your first
name because people in the US usually call first name.
----------------------
>> 1)
>> There are 2types of organizations.
>> One is the organization registered in the QIIS, "Tokyo Shoko Research".
>> The applicant information is obtained from the reliable independent
>> source.
>
> I understand that this is much like an organizational credit reporting
> agency?
Yes, it is.
Tokyo Shoko Research (TSR) is a member of the D&B Worldwide Network since
2005.
http://www.tsr-net.co.jp/english/
>> 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.
>
> I believe that 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.
Yes, this is a "chop".
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.
> The 'certificate of seal impression': Is it possible for any entity
> other than the organization to obtain a copy of the impression to
> compare against?
No, it is impossible.
> Is it possible to send the certificate of
> registration to the issuing local government for authentication?
No, it is impossible.
> A separate statement with an original (not photocopied or otherwise
> reproduced) seal from the organization requesting CA service might be
> useful.
>
>> 2)
>> 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 1), and ask switchboard for transfer to the applicant's
>> representative.
>
> Out-of-band verification of authority to use the organization's name,
> utilizing authoritative information (i.e., contact information from
> something much like Dun & Bradstreet)? I perceive this as acceptable.
> However, for those organizations not registered in the QIIS, I cannot
> perceive this as an effective issuance control (there is no other
> reliable independent source described).
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.
Best regards,
Hisashi Kamo
"Kyle Hamilton" <aero...@gmail.com> wrote in message
news:mailman.2916.1310771020....@lists.mozilla.org...
Kathleen Wilson
> certificate, and turn on all three trust bits.
>
> SECOM Trust Systems is a Japanese commercial CA that provides SSL and
> client certificates for e-Government and participated several projects
> for financial institutions to ensure the secured on-line transactions.
> SECOM provides information security services, including authentication
> and secure data center management services, as well as safety
> confirmation services, which assist companies in the event of a
> large-scale disaster.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=540510
>
> Noteworthy points:
>
> * Cert Download URL:
> https://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer
>
> * This is the SHA256 version of the “Security Communication RootCA1”
> (SHA1) root certificate that is currently in NSS. It will have separate
> intermediate CAs for signing certificates for SSL, EV SSL, email, and
> code signing.
>
Thank you to those of you who have contributed to this discussion.
The following points have been clarified.
1) There are 2 procedures for organization verification. The first
procedure applies when the organization is registered in the QIIS, so
SECOM can query the QIIS regarding the organization's existence. The
second procedure applies when the organization is not registered in the
QIIS. In this case SECOM verifies the "Certificate of seal impression"
on a document that is only issued to a representative of the
organization by the Legal Affairs Bureaus of Ministry of Justice. It is
not possible for an entity other than the organization to obtain a copy
of this document.
2) The same organization and identity verification procedures used for
SSL certificates are also performed for code signing certificates.
3) This root certificate will sign the “Security Communication EV
RootCA2” intermediate CA, which will sign the “SECOM Passport for Web EV
CA2” intermediate CA, which will sign end-entity EV SSL certificates.
Note that SECOM is not requesting EV treatment for this root at this time.
I do not see a need for SECOM to update their CP/CPS documentation in
regards to this discussion. Please respond if anyone disagrees.
If there are no further questions/comments regarding this request, then
I will propose that this request be approved.
Kathleen
Kyle Hamilton
Thank you for clearing up my confusion on the proper form of address.
On Tue, Jul 19, 2011 at 2:16 AM, Hisashi Kamo <h-k...@secom.co.jp> wrote:
>> I understand that this is much like an organizational credit reporting
>> agency?
>
> Yes, it is.
> Tokyo Shoko Research (TSR) is a member of the D&B Worldwide Network since
> 2005.
> http://www.tsr-net.co.jp/english/
> Yes, this is a "chop".
> 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".
> Ministry of Justice.
> 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.
>> The 'certificate of seal impression': Is it possible for any entity
>> compare against?
>
> No, it is impossible.
>> Is it possible to send the certificate of
>> registration to the issuing local government for authentication?
>
> No, it is impossible.
>> Out-of-band verification of authority to use the organization's name,
>> utilizing authoritative information (i.e., contact information from
>> something much like Dun & Bradstreet)? I perceive this as acceptable.
>> However, for those organizations not registered in the QIIS, I cannot
>> perceive this as an effective issuance control (there is no other
>> reliable independent source described).
>
> In stead of getting the information ourselves from QIIS directly, however we
> get the Certificate of seal impression that is equally or more reliable
> 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.
(The LAB must have a copy of the Certificate of Seal Impression, for such things as tax verifications; does it only service financial institutions and the government? I am not completely familiar with Japan's culture or law, and most of my exposure to it comes from movies like Marusa no onna and friends who have taught English in Japanese schools and/or negotiated with large Japanese business.)
Once a forgery is in place, there appears to exist no effective "fallback" protection. In other words, if the security of one portion of the system is compromised the entire system is compromised as far as that forgery goes.
> Best regards,
> Hisashi Kamo
I do, most humbly, apologize for my caution and concern.
Best regards,
-Kyle H
Kathleen Wilson
Thanks again to all of you who have participated in this discussion.
There is one concern currently being discussed, which I will summarize
here, and then recommend closing the discussion and approving this
inclusion request.
--
SECOM has 2 procedures for organization verification. The first
procedure applies when the organization is registered in the QIIS, so
SECOM can query the QIIS regarding the organization's existence, and get
a phone number that they use to contact the organization. QIIS is
provided by Tokyo Shoko Research (TSR), a member of the D&B Worldwide
Network.
http://www.tsr-net.co.jp/english/
The second procedure applies when the organization is not registered in
the QIIS. In this case SECOM verifies the "Certificate of seal
impression" on a document that is only issued to a representative of the
organization by Japan’s Legal Affairs Bureaus of Ministry of Justice.
In the second case, SECOM’s procedure is to look at the “Certificate of
seal impression” to see if it is authentic, and then use the phone
number from that document to call the organization, and ask the
switchboard for transfer to the applicant’s representative.
The concern is that it is believed that this “Certificate of seal
impression” document can be falsely created.
From SECOM: “the certificate of seal impression is equally high enough
reliable as passport or driving license. And printing quality of the
certificate of seal impression is the same highest level as paper money
(bill or note) and reliability is something special.”
SECOM believes that their employees would be able to determine if the
document was falsely created or modified, due to the watermark (chop) on
the document, and the certificate request would be denied.
Most people in the discussion forum are satisfied with SECOM’s procedure
regarding the “Certificate of seal impression” document, because it
follows Japanese custom and business practices. However, a couple people
in the discussion believe that it would not be very difficult to create
a false document with the "certificate of seal impression", so there
should be an additional check as per the Mozilla CA Certificate Policy.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
"7. We consider verification of certificate signing requests to be
acceptable if it meets or exceeds the following requirements:
- all information that is supplied by the certificate subscriber must be
verified by using an independent source of information or an alternative
communication channel before it is included in the certificate;"
--
To bring this discussion to closure…
Possession of this “certificate of seal impression” document is seen as
proof of business identity in other commercial contexts in Japan,
including banks. SECOM has been following this procedure for many years
and I have never heard of a complaint about SECOM inappropriately
issuing certificates.
Technically it could be argued that the procedure does not fully comply
with section 7 of the Mozilla CA Certificate Inclusion Policy. However,
I am exercising my discretion to assert that SECOM’s documented and
audited process for organizational verification is sufficient to allow
for inclusion of this root certificate in NSS and to enable all three
trust bits.
If there are no other concerns regarding this request, then I will close
this discussion and recommend approval in the bug.
Kathleen
Kathleen Wilson
> (SHA1) root certificate that is currently in NSS. It will have separate
> intermediate CAs for signing certificates for SSL, EV SSL, email, and
> code signing.
Thank you to those of you who reviewed this root inclusion request from
SECOM and contributed to this discussion.
During this discussion the following items were discussed.
1) There are 2 procedures for organization verification. The first
procedure applies when the organization is registered in the QIIS, so
SECOM can query the QIIS regarding the organization's existence. The
second procedure applies when the organization is not registered in the
QIIS. In this case SECOM verifies the "Certificate of seal impression"
on a document that is only issued to a representative of the
organization by the Legal Affairs Bureaus of Ministry of Justice.
Technically it could be argued that the second procedure does not fully
comply with section 7 of the Mozilla CA Certificate Inclusion Policy.
However, this practice is followed in other commercial contexts in
Japan, including banking. Additionally, no concerns have been raised
regarding SECOM’s past issuance of certificates. Therefore, I have
asserted that SECOM’s documented and audited process for organizational
verification is sufficient to allow for inclusion of this root
certificate in NSS and to enable all three trust bits.
2) SECOM clarified that the same organization and identity verification
procedures used for SSL certificates are also performed for code signing
certificates.
3) SECOM clarified that this root certificate will sign the “Security
Communication EV RootCA2” intermediate CA, which will sign the “SECOM
Passport for Web EV CA2” intermediate CA, which will sign end-entity EV
SSL certificates. Note that SECOM is not requesting EV treatment for
this root at this time.
This concludes the public discussion about SECOM's request to add the
“Security Communication RootCA2” root certificate, and turn on all three
trust bits.
I will post my recommendation for approval of this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=527419
All follow-up on this request should be posted directly in the bug.
Thanks again to all of you who have participated in this discussion.
Kathleen