Secom It

[Emerson Mata]

SECOMTrust 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:

_bug.cgi?id=527419And in the pending certificates list here:

Gathering Document:

=540510Noteworthy points:* Cert Download URL:

-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:

-Root/SCRootCPS.pdfSubordinate CA Certificate Policy:

-Root/SCRootCP1.pdfCA Service Passport for Web SR 2.0 Certificate Policy:

-CP.pdfCA Passport for Web EV Certificate Policy:

-CP.pdfEV Verification Document:

=451885CA Passport for Member 20 PUB Certificate Policy:

-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( ))

(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 daigaku4-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:

COM, NET, ORG domain: -bin/whois/whois

Other than the above: -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:

COM, NET, ORG domain: -bin/whois/whois

Other than the above:

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: * CRL: -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, =1087. The 2011 audit is

currently in progress.Potentially Problematic Practices

( :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

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

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.--

RegardsSigner: Eddy Nigg, StartCom Ltd.

XMPP: star...@startcom.org

Blog:

Twitter: _nigg

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 -----Ursprngliche Nachricht-----Message: 2

Date: Mon, 11 Jul 2011 15:33:37 -0700

From: Kathleen Wilson

> * 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.

"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 wrote in message

news:mailman.2527.1310469973....@lists.mozilla.org...

"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".

3a8082e126