435026 - Add Swiss BIT Root certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Beatrice Metaj-Rimo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 

	
Company name and address:
Bundesamt für Informatik und Telekommunikation (BIT)
Monbijoustrasse 74
CH - 3003 Bern

(Federal Office of Information Technology and Telecommunica-tion (FOITT) )

Company Web page ad-dress:	www.bit.admin.ch

Number of roots to be submitted:	2

1) Admin-Root-CA.crt	exp.: 11/10/2021 (month/day/year)
Fingerprint (SHA-1) 25:3f:77:5b:0e:77:97:ab:64:5f:15:91:55:97:c3:9e:26:36:31:d1

2) AdminCA-CD-T01.crt		exp.: 01/25/2016 (month/day/year)
Fingerprint (SHA-1) 7c:14:fd:21:42:0c:bf:63:35:cb:25:31:72:5d:fb:8a:d8:6a:61:94

Business purpose of certificates issued from these roots:	E-Government activities of the Swiss Confederation

To whom are certificates issued:	Federal administrations, swiss cantons, communities and organizations in possession of the public administration.

Extended key usage required for both roots:	Equivalent to Microsoft Key usages: 

Server authentication
Code Signing
Time Stamping
Trust List Signing 
Microsoft Time stamping
IP security end system
IP security tunnel termination
IP security user
Encrypting File System
Windows Hardware Driver Verification
Windows System Component Verification
OEM Windows  System Component Verification
Embedded  Windows System Component Verification
Key Pack Licenses
License Server Verification
Smart Card Logon
Digital Rights
Qualified Subordination
Key Recovery
Document Signing
IP security IKE intermediate
File Recovery
Root List Signer
All application policies
Directory Service Email Replication
Certificate Request Agent
Key Recovery Agent
CA Encryption Certificate
Lifetime Signing

Please refer to the issuing process described in the CPS published on:
http://www.pki.admin.ch/policy/CPS_2_16_756_1_17_3_1_4.pdf

CP/CPS	http://www.pki.admin.ch/policy/CPS_2_16_756_1_17_3_1_4.pdf

Third party auditing company:
KPMG SA (Klynveld Peat Marwick Goerdeler SA)
Information Risk Management
Badenerstrasse 172
CH- 8004 Zürich
Tel: [phone]
FAX: [phone]
www.kpmg.ch 

Broad value to Mozilla customers:
Some Federal administrations, swiss cantons, communities and organizations in possession of the public administration are using the Mozilla products.

AdminPKI Homepage (Root certificates, CRL, Test-certificates…):	www.pki.admin.ch  Rootzertifikate („Klasse A“ & „Klasse C&D“)



Reproducible: Didn't try

Steps to Reproduce:
1.
2.
3.



Our company’s PKI Trust Centre was certified on July the 4th 2007 by KPMG SA Switzerland (Klynveld Peat Marwick Goerdeler SA). Please add our Rootcertificates to Mozilla products.

Please contact me in case you need further information.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request. :)

Comment 2

[Kathleen Wilson]

Accepting this bug so I can proceed with the information-gathering phase.

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the initial information gathering document which summarizes the information that has been gathered and verified. Within the document the items highlighted in yellow identify where more clarification or data is needed. I will summarize below.

1) Would it be possible to get the corresponding CPS’s for these 2 roots translated into English?

2) Which CPS(s) correspond to the AdminCA-CD-T01 root?

It appears that the CPS’s corresponding to Admin-Root-CA are
CP/CPS AdminPKI - ClassA (AdminCA-A-T01 sub-CAs)
http://www.pki.admin.ch/policy/CPS_2_16_756_1_17_3_1_4.pdf

CPS for AdminPKI-Class B 
(Admin-CA2 and Admin-CA3 sub-CAs)
http://www.pki.admin.ch/policy/CPS_2_16_756_1_17_3_1_3_FR.pdf


3) Please confirm or correct this information for the hierarchy for Admin-Root-CA
Admin-Root-CA issues the following 3 internally operated CAs:
-> AdminCA-A-T01
-> Admin-CA3
-> Admin-CA2

AdminCA-A-T01 issues Class A certificates – HW (Token) – Personal Identification - Legally binding signature
 
Admin-CA2 and Admin-CA3 issue Class B certificates – HW (Token)  -- Personal Identification – Signature, Encryption, Authentication

4) Please confirm or correct this information for the hierarchy for Admin-CA-CD-T01
Admin-CA-CD-T01 issues end-entity certificates directly:
Class D Certificates – Soft-Token – Administrative Identification – Authentication
Maschinen (Machine) Certificates – Soft-Token – Administrative Identification -- Authentication
CodeSigning Certificates – HW or SW Token – Personal Identification – Only Signatures

5) For each of these roots, are there any subordinate CAs that are operated by third-parties?

6) Have either of these roots been used to cross-sign other CAs?

7) Please translate into English the sections/text in the corresponding CPS’s that demonstrate that reasonable measures are taken to verify the following information for end-entity certificates chaining up to these roots, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a)for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
b)for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; 
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

8) Please identify if all SSL certs chaining up to these roots are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber.

Are there any SSL certs chaining up to this root that are only DV? Eg the Organization attribute is not verified, only the domain name is verified?

Please provide the English-translation of the text in the CPS’s that explains the process for verifying the identity/organization.

9) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. 
Would you please comment as to whether any of these are relevant?
If relevant, please provide further info and the corresponding translations from the CPS's.

10) The thumbprint for the AdminCA-CD-T01 root didn’t match what was in bugzilla. Please review the root data in the attached document to confirm if the correct root is being evaluated.

11) What is the maximum update frequency for end-entity certificates? I believe section 4.9.7 and 4.9.8 has the information I need for Admin-Root-CA. Would you please translate those sections into English?
 
12) Please provide a link to the most recent public audit statement/report.

Thanks,
Kathleen

Comment 4

[Beatrice Metaj-Rimo]

Bugzilla ID: 435026
Bugzilla Summary: Add Swiss BIT Root certificate

I'll send you an e-mail Kathleen!

Regards
B. Metaj

Comment 5

[Kathleen Wilson]

Attachment: KPMG Audit Statement

Comment 6

[Arthur]

@Kathleen: So are still all points from comment 3 except point 12 open or has there been more progress? OS X/Safari and Windows/IE already have the root certificates.

If there is translation work to do I'll probably could find some time in May.

Comment 7

[Kathleen Wilson]

Attachment: English Translation of CPS for Admin-Root-CA

Comment 8

[Kathleen Wilson]

Attachment: English Translation of CPS for AdminCA-CD-T01

Comment 9

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

I am providing this update in bugzilla, because the communication has been happening via email.

Here’s my last request that was sent to Beatrice via email:
--
According to my notes I am looking for the following information for this request:

1) I made a note that the CPS is being updated. Is there a new version I should refer to?

2) Please point me to the text in the CPS that satisfies section 7 of http://www.mozilla.org/projects/security/certs/policy/. For AdminCA-CD-T01 need to find that the ownership of the domain name and email address referenced in the cert is checked. 

3) Please identify if any of the practices listed in http://wiki.mozilla.org/CA:Problematic_Practices
is applicable to either Admin-Root-CA or AdminCA-CD-T01, and provide further info where applicable.
--

Beatrice responded that she is working on this and will reply when she has all of the information.

Other than these items, the only other thing we’ll need is the url to a website (can be a test site) whose website certificate chains up to the AdminCA-CD-T01 root.

Comment 10

[Beatrice Metaj-Rimo]

Hi Kathleen

We're still working on your last requests. We'll deliver the answers to you as soon as we have finished updating our CPS!

Regards
Beatrice

Comment 11

[Beatrice Metaj-Rimo]

Attachment: New Version of CP/CPS Klasse CD-T01

Dear Kathleen

I will attach the new version of our CP/CPS here. The corrected chapters (Nr. 4 & 5) shoud satisfy your question 1 and 2 of the mail below.

For question 3) none of these practice is applicable to either Admin-Root-CA or AdminCA-CD-T01.

Many thanks and Regards 
Beatrice

Comment 12

[Kathleen Wilson]

Attachment: Admin-Root-CA

Comment 13

[Kathleen Wilson]

Attachment: AdminCA-CD-T01

Comment 14

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Dear Beatrice,

Thank you for the updated CP/CPS for AdminCA-CD-T01.

Would you please review the attached document for accuracy/completeness? Please be sure to review the “Flag Problematic Practices” section at the end of the document.

I am still unable to figure out how Section 7b of http://www.mozilla.org/projects/security/certs/policy/ is met: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;”

Please explain and indicate which parts of the CP/CPS address this.


When I try to import http://www.pki.admin.ch/crl/AdminCA-CD-T01.crl into Firefox, I get Error Code:ffffe095.
ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION
Please see https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

For testing purposes, would you please provide a url to a website whose SSL cert chains up to the AdminCA-CD-T01 root?

Would you also please attach to this bug a test cert that chains up to the Admin-Root-CA root? 

Thanks,
Kathleen

Comment 15

[Beatrice Metaj-Rimo]

Attachment: Provisioning Servercertificates - Process description

Dear Kathleen

1) We have our guidelines and processes how to verify the entity submitting the certificate signing request described in the manual document (attached) and not in the CP7CPS. We only have a German version of it. Basically the persons are being equipped with a qualified certificate to assure a strong authentication on the provisioning platform application (personal identification with passport / identity card and badge with position description in their firm). Afterwards they're getting authorized by certificate on the domain where they can afford their certificates only for this single domain. The request formulary has to be signed by the director of their office. I attach also the formulary if you need it!

2) To jour second question: We have this critical extension 8Flag at "issuing distribution point" only in our CD-T CA. This will be corrected by the end of June, as this is not a necessary flag an can be omitted, by our guidelines.

3) Here are some URLs where you can test the root:
https://www.medreg.admin.ch/

https://www.astra.admin.ch/
Actually you will need to have a password to continue, but the site should open up to this point and you can check the root.


4) You would need to get a hard token certificate with password and would need to be identified personally. If you want such a test certificate we can create an impersonal test certificate on a hard token (SmartCard9, as our end-user certificates are on hard tokens, and sent it to you by post. You can then afford your password by phone. We use DataKey cards so be sure to have a SmartCard reader an the driver for this. Please give me a notification if we should send it to you and inform me where to send it!


Many thanks and Regards
Beatrice Metaj

Comment 16

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 17

[Kathleen Wilson]

This request has been added to the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
The status column indicates where we are in the queue, which is the request
whose status is “In First Discussion”. Most first discussions take one to two
weeks. Since the discussions are dependent on volunteers reviewing and
commenting on the requests, I try to limit the first discussions to one active
discussion at a time.

A description of the public discussion process is available at
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

In the meantime, please post the following information to this bug when it becomes available:

1) Notification when the critical extension flag for the IDP of the CD-T01 crl has been removed.

2) The auditor’s statement from the 2009 Surveillance Audit that meets the requirements of sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

Comment 18

[Beatrice Metaj-Rimo]

Hi Kathleen

1)The critical extension flag has already been removed for the IDP of the CD-T01 crl.

2) The auditor's statment has been requested from KPMG. As soon as I have the writing I will add the attachment to this Bug.

many thanks
and kind regards

Beatrice Metaj-Rimo 
Order Manager 

Eidgenössisches Finanzdepartement EFD
Bundesamt für Informatik und Telekommunikation BIT
PKI & Sicherheitsprodukte

Comment 19

[Kathleen Wilson]

> 1)The critical extension flag has already been removed 
> for the IDP of the CD-T01 crl.

Thanks.  I am now able to import the CRL into Firefox without error.

Comment 20

[Beatrice Metaj-Rimo]

Attachment: KPMG Letter (June 2009)

Dear All 

here attached the last KPMG letter as requested.
can you already give us an approximate timeline when our certificates will be implemented?
Thanks fo a short information.

Best Regards and many thanks
Beatrice Metaj

Comment 21

[Kathleen Wilson]

> here attached the last KPMG letter as requested.

Thanks. I have sent email to KPMG to confirm the authenticity of the audit statement as per Mozilla process.

> can you already give us an approximate timeline when our certificates will be
> implemented?

The best I can do is to say that it will still be several months.  First the request needs to get through public discussion.  As per https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion there are 11 requests in front of yours, waiting for their first public discussion.  Each discussion usually takes 1 to 2 weeks. After the discussion, if all goes well, there is an approval phase which usually takes a couple of days, and after approval I will create a new bug for tracking the actual changes to NSS. It can take a couple of months for the NSS changes to be done and added to a release.

Comment 22

[Kathleen Wilson]

I have exchanged email with KPMG AG (Switzerland) to confirm the authenticity of the newly attached audit statement. KPMG has confirmed that the Surveillance Audit was performed and completed in the first quarter of this year, as indicated in the statement.

Comment 23

[Philipp Langenegger]

I am now the representative for Swiss BIT for this request, concerning the absence of Beatrice Metaj. Thanks

Comment 24

[Kathleen Wilson]

In preparing this request for the upcoming public discussion, I am re-reviewing the information.  As such, I have some questions in regards to verifying that the certificate applicant owns/controls the domain name to be included in the SSL certificate…

It looks like there is a self-service application for issuing SSL certificates called the provisioning platform application.

Who can get a qualified certificate for authentication into the provisioning platform application? Where is this documented? Who approves these certs and which access/abilities they have in the application?

Once a person is able to authenticate into the provisioning platform application, what domain names can they issue SSL certs for?  How is it determined which domain names they can issue SSL certs for?  How is this enforced?  Where is this documented?


I also have another slightly different question…
The current request is to enable the Websites, Email, and Code Signing trust bits for the AdminCA-CD-T01 root. Where are the procedures documented for the issuance of code signing certificates?

Comment 25

[Philipp Langenegger]

Dear Kathleen

As you can see on page 26 of CP/CPS Class CD-T01, only authorised persons can issue/revoke certificates in this webbased application (provisioning platform):

- "The authorised person (see section 1.3.2) makes a request to AdminPKI for himself and a deputy to be admitted to the registration application for the relevant domain (e.g. sedex, group mailboxes, class D etc.). These persons must be authorized by the director of their administrative unit and must have passed the “personal security check” of the federal department of defence (“Personensicherheitsprüfung”). Registration officer get a private course from the AdminPKI for their new task, and have to pass to regular quality checks and external auditings."

If a person is authenticated into the provisioning plattform application, they can issue SSL certificates for any domain. We have therefore no enforced measures, but our Security Officers are observing and checking the system weekly for wrong and not legally issued certificates and entries, as you can see also on page 26 of our CP/CPS for Class CD-T01:

- "The AdminPKI Security Officers observe the system and check regularly the databases for wrong or not legally issued certificates and entries."

The Code Signing procedures are documented on the request forms for CodeSigning Certificates (we have it only in german). Basically the person who requests a Code Signing Certificate must also be a authorised person (page 26 CP/CPS), but the issuing is diffrent: After the personal identification of this person, the AdminPKI itself is issuing the requested CodeSigning Certificate and delivers it personally to the requester.

Thanks and Regards
Philipp

Comment 26

[Kathleen Wilson]

If I understand this correctly, then once someone becomes an authorised person, they can use the registration application to issue SSL certificates for any domains that they want. They are not required to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. And the only mechanism for catching the issuance of an SSL certificate to a domain that they don’t own is a manual check from a Security Officer that happens once a week.

Previously I had been under the impression that the authorised person would only be able to issue SSL certificates within domains that they had been authorised for. (So I was curious about how the authorised person was determined to be able to issue SSL certs within that domain)

Comment #15: …Afterwards they're getting authorized by certificate on the domain where they can afford their certificates only for this single domain. The request formulary has to be signed by the director of their office. 

Perhaps I do not understand correctly, so I’ll try from the approach of stating Mozilla’s requirements…

We need each CA to have documented and audited procedures for confirming that the subscriber of each SSL certificate owns/controls the domain name to be included in the certificate.

From section 7 of the Mozilla CA Certificate Policy
http://www.mozilla.org/projects/security/certs/policy/
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: 
for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;

From recommended practices
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
WHOIS may be used by some CAs as a source of information for checking ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.

Comment 27

[Kathleen Wilson]

Philipp, Do you have further information that you can provide to clarify how Mozilla's requirements for verification of the ownership/control of domain names for SSL certs are met and documented? (please see Comment #26)

Comment 28

[Philipp Langenegger]

Yes i do: Fist it is important to understand that these authorised person are specially selected by the chief of their departements/organizations (AdminPKI issues certificates only for the federal government and canton departements in switzerland) . They get an education and have to pass security audits. Even if they can issuce Certificates from any Domain (Comment 15 is unfortunately in this point not correct, sorry), they are not allowed to do so. They are only authorised to issue Certificates for their Departement/Organization and they are aware of the cosequences a misuse. (See CP/CPS page 26)

Now to your question: To avoid misuse, the security officer have to observe the system once per week for wrong or ilegally issued certificates, as described in the CP/CPS on page 26:

-"The AdminPKI Security Officers observe the system and check regularly the
databases for wrong or not legally issued certificates and entries."

In Detail, the security officers receive reports. In these reports is declared, which authorised person has issued each specific domain, including organization/departement name, address, Issuing Date, and so on... The security officer now checks these reports for suspicious  elements (if domain is not a subdomain of admin.ch, it is suspicious because AdminPKI only issues Certificate for federal governemnet and cantonal departements). If such elements were found, he checks if domain and authorised person matchs with different WHOIS querys. If not, he has to revoke the certificate and send a notice to the specific chief of departement, respective his office.
With all the other elemtens, which are not suspicious, the security officer makes random checks with the same methodes as described before.

This whole process is described in the internal security officer process (only in german). If you wish i can upload the file. 

In the current Release of the Provisioning Platform, the AdminPKI handles these security issues reactive. In further release, it will be most likely proactive.

I hope that these informations provides you a clearer view for the whole process.

Comment 29

[Kathleen Wilson]

Philipp, Thank you for the clarification. 

Note that your request is next in the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I will post an update in this bug to inform you of when I start the discussion.

Comment 30

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 31

[Kathleen Wilson]

Philipp, I just noticed that the test websites that were provided Comment #15 don't appear to be valid. The SSL cert for one is issued under a different root, and the other website URL doesn't appear to work.

Please provide the url to a website whose SSL cert chains up to the “AdminCA-CD-T01” root.

Comment 32

[Philipp Langenegger]

Yes that's true. Since june 2009 there have been some changes. Here a website with the correct Root:

https://www.aramis.admin.ch/

Comment 33

[Philipp Langenegger]

Yes that's true. Since june 2009 there have been some changes. Here a website with the correct Root:

https://www.aramis.admin.ch/

Comment 34

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated test website -- works for me.

Comment 35

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Swiss BIT to add two root certificates. The request is to enable the email trust bit for the “Admin-Root-CA” root, and to enable all three trust bits for the “AdminCA-CD-T01” root.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Swiss BIT Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of the CA should promptly respond directly in the discussion thread to all questions that are posted.

Comment 36

[Steve Roylance]

Dear all,

I've noticed that the test web site https://www.aramis.admin.ch/ has an end entity certificate issued directly from the root itself.  This seems to be against the advice on the problematic practices page.  

Issuing end entity certificates directly from roots 
Some CAs issue end entity certificates directly from the root (i.e., signed using the root CA private key). This is not as secure as using an offline root and issuing certificates using a subordinate CA.

I feel it's worth mentioning to see if this is 'normal' practice.

Kind Regards, Steve Roylance (GlobalSign)

Comment 37

[Alpaslan]

   I would like to mention that due to "Potentially problematic CA practices" document practices are not explicitly addressed by the Mozilla CA certificate policy, and Mozilla do not necessarily consider them security risks.  I agree with Mr. Roylance than using an offline root is more secure but this structure could be an organizational decision for some special needs. 

   There is not any opposite criteria in Mozilla CA Certificate Policy . Although criteria 13 is related to this issue , it is a recomendation not a requirement. 


Kind Regards,
Alpaslan BİNİCİ

Comment 38

[Kathleen Wilson]

The public comment period for this request is now over. 

The concern about the generic issuer/subject information in the root certificates was deemed to be a show stopper for inclusion. It is recommended that Swiss BIT seek an alternative, such as having their roots cross-signed by another CA who's root certificate is included in NSS.

The issuer and subject information in the certs is as follows.

CN = Admin-Root-CA
OU = Certification Authorities
OU = Services
O = admin
C = ch

CN = AdminCA-CD-T01
OU = Certification Authorities
OU = Services
O = admin
C = CH

Comment 39

[Philipp Langenegger]

Hi Kathleen

We cannot accept this. At least we expect the opportunity to correct the specified issues. As we already mentioned, we assure that each of those issues can and will be solved within a reasonable time.
So please reopen this request and specify once again the detiald issues we have to correct, so if done the second public discussion can be started.

Thank You
Regards
Philipp Langenegger
SwissBIT

Comment 40

[Eddy Nigg (StartCom)]

Philipp, I think you may be able to reopen this bug or file a new bug when you are ready. Considering that the issues are the CA root certificates themselves, I suspect that this will take a while until you signed new roots and Kathleen will probably have to request another audit report. 

As such you are completely right and entitled to try it again.

Comment 41

[Kathleen Wilson]

If a new root is created in order to solve the concern about the root cert issuer/subject as per Comment #38, then that new root will need to be included in appropriate CP/CPS documentation and an audit, and a new root inclusion request bug may be created. The new request would go through the root inclusion process as described in https://wiki.mozilla.org/CA:How_to_apply.

The other items that were noted in the discussion and would also need to be addressed are as follows.

1) Verification of Domain Name as per section 7 of the Mozilla CA Policy

Concern was raised that domain name verification happens as part of an audit after the certificate has been issued.

The CA responded: …only trained personnel is authorized to issue certificates. These people belong to the government and are audited. The issuance of a SSL-certificate is not possible without strong authentication (by means of a smartcard “class B” that is issued with a personal face-to-face registration on behalf of the passport). That means, that there exists a strong audit trail, so that wrong usage can and will lead to serious legal consequences for the respective employee.

Precedence has been set with other CAs that the procedures for verifying that the certificate subscriber owns/controls the domain name included in the certificate must be done before the certificate may be issued.

ACTION Swiss BIT: Update Swiss BIT’s practice to verify that the certificate subscriber owns/controls the domain name to be included in the certificate before the certificate may be approved for issuance. Update the CPS documents to describe the new procedures. Obtain an audit that meets the requirements of the Mozilla CA Policy that confirms that the new procedures are in place as documented.

2) Verification of Email Address as per section 7 of the Mozilla CA Policy

Concern was raised that email address verification procedures do not meet the requirements of section 7 of the Mozilla CA Policy.

As is documented in the CPS documents: The Federal Administration maintains a meta-directory called the Admin-Directory. Employees of an administrative unit (federal, cantonal or municipal administration) are registered in the Admin-Directory. Anyone whose personal data are published in the Admin-Directory may complete the certificate application form. The Registration Authority compares the information in the certificate application with the data in the Admin-Directory, including the subscriber’s last and first names, distinctive hash code, and e-mail address. The consent of the administrative unit employing the subscriber is required for publishing the certificate in the public version of the Admin-Directory. The applicant is notified by e-mail of the issuance of the certificate. The e-mail address in the certificate is used for this purpose.

My understanding is that the act of an employee being added to the Admin-Directory ensures the accuracy of the data therein, including the email address that is included in the Admin-Directory. However, I do not see clear documentation that the email address to be included in the certificate is confirmed to be the same as the email address in the Admin-Directory. The statement that the certificate is sent via the email address that is included in the certificate is not enough – the check should be performed before the certificate is created.

ACTION Swiss BIT: Update Swiss BIT’s CPS documentation to further clarify the verification procedures for confirming that the certificate subscriber owns/controls the email address to be included in the certificate.

Comment 42

[Kathleen Wilson]

Re-opening this bug, because the CA has indicated that they are creating a new root certificate, they will respond to Comment #41 soon, and they would like to proceed with this root inclusion request (with a new root and updated CPS as per the first discussion).

Comment 43

[Philipp Langenegger]

Attachment: New Root CA Certificate

Comment 44

[Philipp Langenegger]

Attachment: Swiss Government Root CA II CP/CPS

CP/CPS for the Swiss Government Root CA II

Comment 45

[Philipp Langenegger]

Below the answers to the issues above. 

Issue 1:
The applicant gets checked against a database if he has the authorization to issue a certificate with the specific domain name (CP/CPS, p. 23, section 3.2.3). If the applicant is not the owner of the domain himself, he must be authorized for the specific domain based on a official approval from the owner of the domain. All this happens before the issuance.
Issue 2:
All the information required to identify the applicant is verified. For example if the request for a Server Certificate contains an e-mail address, it is checked before the issuance of the certificate (CP/CPS, p.23, section 3.2.4). To state this more precise, the e-mail of the certificate gets checked over an activation-mail procedure.

Comment 46

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

The attached document summarizes the information that has been verified for the new "Swiss Government Root CA II" root certificate and related documentation.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 47

[Beatrice Metaj-Rimo]

Dear Kathleen

I'd like to introduce one of our Security Officers to you, as he will take ower the reports for this bug.
[e-mail] will help us with the solution reports for the introduction of our roots into Mozilla.
Shoud I introduce him in a special list in order for him to be able to report to this bug? How can he get included into the contactlist?

Kind Regards
Beatrice and many thanks for your help!

Comment 48

[Beatrice Metaj-Rimo]

I've added Jürgen into the cc: list.

Comment 49

[Kathleen Wilson]

(In reply to Beatrice Metaj-Rimo from comment #47)
> Dear Kathleen
> 
> I'd like to introduce one of our Security Officers to you, as he will take
> ower the reports for this bug.
> [e-mail] will help us with the solution reports for the
> introduction of our roots into Mozilla.

Thanks for the introduction.

> Shoud I introduce him in a special list in order for him to be able to
> report to this bug? How can he get included into the contactlist?

Now that you've added Jürgen to the CC list of this bug, he will automatically get notified whenever the bug is updated.

Comment 50

[Kathleen Wilson]

Jürgen, welcome to this bug.  Please begin by responding to Comment #46 and adding the requested information to this bug.

Comment 51

[juergen.weber]

Attachment: Revised CP/CPS of Swiss Government Root CA II

Comment 52

[juergen.weber]

Attachment: SG_Root_CA_II_Bugzilla_ID_435026_V1.0 (CA:Information checklist)

Our opinion on the Mozilla CA requirements

Comment 53

[juergen.weber]

Kathleen, thank you for being welcomed in the list.

As you may know, we have revised completely the CP/CPS of Swiss Government Root CA II.
We have also completed the Mozilla checklists as required (CA:Information checklist)

You can find them in the attachements:

Attachment: Revised CP/CPS of Swiss Government Root CA II
Attachment: SG_Root_CA_II_Bugzilla_ID_435026_V1.0 (CA:Information checklist) 

I look forward to your feedback.

Kind regards
Jürgen

(In reply to Kathleen Wilson from comment #46)
> Created attachment 549415 [details]
Updated Information Gathering Document
> The attached document summarizes the information that has been verified for
> the new "Swiss Government Root CA II" root certificate and related
> documentation.

The items highlighted in yellow indicate where further
> information or
clarification is needed. Please review the full document for
> accuracy and
completeness.

Comment 54

[Kathleen Wilson]

(In reply to juergen.weber from comment #51)
> Created attachment 758548 [details]
> Revised CP/CPS of Swiss Government Root CA II

The version attached to this bug is different (newer) than the one on the website
http://www.bit.admin.ch/adminpki/00243/04407/index.html?lang=de
http://www.pki.admin.ch/cps/CPS_2_16_756_1_17_3_21_1.pdf

Comment 55

[Kathleen Wilson]

Attachment: Updated CA Information Document

Main items still to complete:

- OCSP is required now

- Need link to actual audit statement.
Also, for your next audit, please make sure it meets the requirements of version 2.1 of Mozilla’s CA Certificate Policy
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

- The CA/Browser Forum’s Baseline Requirements are required for all root certs with the Websites (SSL/TLS) trust bit enabled.
https://www.cabforum.org/documents.html
Please carefully review the Baseline Requirements document, and update your CA practices and policies accordingly.


- Please also respond to https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
Version 2.1 of Mozilla’s CA Certificate Policy was published in February, and is available here:
http://www.mozilla.org/projects/security/certs/policy/

Comment 56

[michael.vonniederhaeusern]

Hi Kathleen
I would like to reopen this bug to continue with the Swiss Government Root CA III.
This new Root CA is the replacement for the Swiss Government Root CA II to issue Publicly Trusted Certificates.
Regards
Michael

Comment 57

[michael.vonniederhaeusern]

Attachment: RootCAIII.cer

Swiss Government Root CA III Certificate

Comment 58

[michael.vonniederhaeusern]

Attachment: 0067-RV-CP-CPS Root_CA_III_2_16_756_1_17_3_61_0.pdf

Swiss Government Root III CP/CPS (not digitally signed version)

Comment 59

[Kathleen Wilson]

Michael, For the new root please provide the information listed here:
https://wiki.mozilla.org/CA:Information_checklist

Francis, Please do the Information Verification and enter the data into Salesforce for the new root certificate (Comment #57) and the new CP/CPS (Comment #58).

Comment 60

[Kathleen Wilson]

Attachment: 435026-CAInformation.pdf

Francis entered the information they he verified so far into Salesforce.

Please review the attached document to ensure it is complete and correct. Also, look for the word "NEED" to see what information still needs to be provided. Provide the requested information and any corrections by posting comments in this bug.

Comment 61

[Francis Lee [:frlee]]

hi Michael, 

may i know if you have any further update based on comment 60?

thank you very much

Comment 62

[michael.vonniederhaeusern]

hi Francis

We reviewed the CAInformation document you attached and are collecting all information you required.
The new root structure is being audited now and we expect the auditor statement for mid january. We will answer to the open questions in the document as soon as we have received the auditor statement and therefore have collected all documents and test protocols that are required to continue with the inclusion.

thank you for your support

Comment 63

[michael.vonniederhaeusern]

Attachment: BIT Audit Certification Confirmation 2017

Comment 64

[michael.vonniederhaeusern]

hi Francis

We finished the regular audit of our pki and included the new Root III. The audit confirmation has been issued (see attachment 8832816 [details]).
We will now update the CAInformation document accordingly.

thank you

Comment 65

[Francis Lee [:frlee]]

hi Michael,

thank you for your update.
Beside updating CAinformation document, Mozilla has revised our Problematic practices by adding one section called ''Issuer Encoding in CRL'': 
https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
please double check it and let us know if ''Issuer Encoding in CRL'' is specified in your CP/CPS.

thank you very much

Comment 66

[michael.vonniederhaeusern]

hi Francis

We double checked this and we are compliant with this requirement. 
The requirement "Should be byte-for-byte equivalent to the encoding of the Issuer field in the CRL" has been added to the policy document.

Regards
Michel

Comment 67

[michael.vonniederhaeusern]

Attachment: CP/CPS Swiss Government Root CA III Version 1.3 2017-02-03

CP/CPS Swiss Government Root CA III Version 1.3 2017-02-03

Comment 68

[michael.vonniederhaeusern]

Attachment: CAInformation SG PKI response 2017-02-02

Swiss Government PKI response to the open questions from CAInformation document.

Comment 69

[michael.vonniederhaeusern]

Hi Francis

I updated this bug with allrequired information to continue with the inclusion of SG Root III.
in attachment 8833242 [details] you'll find the actual CP/CPS to SG Root III Version 1.3
in attachment 8833247 [details] we reply to the open questions from the CAInformation document

Regards
Michael

Comment 70

[michael.vonniederhaeusern]

Hi Francis

As all required information has now been added to this bug. Is there anything else we can provide to get the public discussion for inclusion of the new root under way?

We are ready to answer all questions in public discussion for inclusion of Swiss Government Root CA III. If something is missing, please let me know.

Regards
Michael

Comment 71

[Aaron Wu]

Attachment: CAInformaion_SwissBit_InfoNeeded_20170309.pdf

Comment 72

[Aaron Wu]

Hi Michael,

It is Aaron Wu who will take over the work of information verification on this case.

please see the attachment as Comment#71. We need your some information input which marked as "Need Response from CA".

For Verifying Email Address Control, you can refer to :
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control

For EV Test, there is an error shown as SEC_ERROR_EXTENSION_NOT_FOUND
Please help to clarify and fix the error, detail please refer to attached file in Comment#71

Thank you so much!

Kind regards,
Aaron

Comment 73

[michael.vonniederhaeusern]

Attachment: successful ev-checker screenshot

Comment 74

[michael.vonniederhaeusern]

Hi Aaron

Thank you for performing these checks.

In our initial application we entered the OID that is used to reference our technical end entity certificate. 
In the certificate itself the correct OID 2.16.756.1.17.3.61.2 is being used. Please change this value in our application to reflect the correct OID. We attached a screenshot of the successfull  ev-checker as attachment 8845916 [details].

We also do not issue DV certificates under this root anymore - as it was specified in the initial application.

You refer to "Verifying Email Address Control". This Email verification is not applicable as we do not use this verification method; we do not require the Email trust bit. 

Email is only used as described in http://www.pki.admin.ch/public/83823_Checkliste-Genehm-SSL-TLS-ZertifAntr-CAs-SwissGov-PKI-160513-e_pub.pdf .

Do you need further information or does this clarify the open issues?

Thank you for your support

Best regards
Michael

Comment 75

[Aaron Wu]

Hi Michael,

Based on the OID you provided in Comment#74, I've updated in Salesforce and run EV Tewith success.
Result : ev-checker exited successfully: Success!

i am doing the final verification and will let you know if need further information. Once all information verified, I will move it to next phase as Public Discussion.

Please stay tuned, thank you so much!

Kind regards,
Aaron

Comment 76

[Aaron Wu]

Hi Michael,

All information are verified and updated in Salesforce, ready for Public Discussion.

Kind regards,
Aaron

Comment 77

[Kathleen Wilson]

Michael,
Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 78

[michael.vonniederhaeusern]

Attachment: SG-PKI Root CA III BR Self Assessment as of 2017-04-18

BR-self-assessment document as Requred in Comment #77 by Kathleen Wilson.

Comment 79

[michael.vonniederhaeusern]

Hi Kathleen

I added attachment 8859143 [details] with the BR self assessment.
If you need more information, please don't hesitate to ask.

Thank you 
Regards
Michael

Comment 80

[michael.vonniederhaeusern]

Hi Aaron

Is there anything we need to supply to continue with public discussion?

Thank you for your support

Regards
Michael

Comment 81

[Aaron Wu]

Hi Michael,

We are reviewing BR Self Assessment and update in Salesforce, sooner the public discussion will be started and forum url will be posted in this bug. Please stay tuned, thank you!

Kind regards,
Aaron

Comment 82

[Aaron Wu]

Attachment: CAInformation_SwissBit_Complete_20170515.pdf

Comment 83

[Aaron Wu]

Hi Michael,

BR Self Assessment has been verified and updated in Salesforce as Comment#82.

Once the public discussion starts, we will inform you and post the forum link here.

Thanks,
Aaron

Comment 84

[michael.vonniederhaeusern]

Hi Aaron

Is there any possibility to line this inclusion request up for public discussion?
I see no actual reason why this has not been done yet.

Regards
Michael

Comment 85

[Aaron Wu]

Hi Michael,

This inclusion is in the queue of "Ready for Public Discussion", please see the link below:
https://wiki.mozilla.org/CA/Dashboard#Ready_for_Public_Discussion

In sequence, we will start this inclusion for public discussion soon, please stay tuned.

Thank you so much!

Best regards,
Aaron

Comment 86

[Aaron Wu]

Hi Michael,

We are proceeding your request and re-verifying the data you provided before public discussion.

As BR Self Assessment you provided, these are the test sites: 

- VALID https://www.valid-ov.pki.admin.ch
- REVOKED https://www.revoked-ov.pki.admin.ch
- EXPIRED https://www.expired-ov.pki.admin.ch

It seems server not found for those sites above.

- VALID https://www.valid-ev.pki.admin.ch
- REVOKED https://www.revoked-ev.pki.admin.ch
- EXPIRED https://www.expired-ev.pki.admin.ch

Please also confirm those EV SSL above is correct, then I will make update in Salesforce.


Thanks,
Aaron

Comment 87

[Aaron Wu]

Hi Michael,

An error occurred during a connection to www.valid-ev.pki.admin.ch. 

  - Invalid OCSP signing certificate in OCSP response. 
  - Error code: SEC_ERROR_OCSP_INVALID_SIGNING_CERT

Also got errors when running https://certificate.revocationcheck.com/www.valid-ev.pki.admin.ch
  - OCSP signing certificate has expired 645h44m50.63683153s ago
  - OCSP signing certificate expires before NextUpdate

Please help to check and fix, thanks!


Kind Regards,
Aaron

Comment 88

[michael.vonniederhaeusern]

Hi Aaron

The error has been fixed. We compiled a short notice of what happened and what steps have been taken:

1)	How your CA first became aware of the problem

Feedback from Aaron Wu.

2)	A timeline of the actions your CA took in response.

CA fixed faulty OCSP configuration immediately after detecting the problem.

3)	Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL certificates with the problem.

CA did not issue any certificates from the affected subCA until the problem was fixed.

4)	A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

No certificates are affected. The problem was a misconfiguration of the OCSP server.

5)	The complete certificate data for the problematic certificates.

No certificates are affected.

6)	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

CA operation did not correctly update the OCSP server configuration when updating the OCSP server certificate. The problem was not discovered because only one test site was affected.

7)	List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The problem was resolved immediately. CA operation must check test sites and OCSP operation after certificate renewal.

If you have further questions, do not hesitate to contact me.

Kind Regards
Michael


(In reply to Aaron Wu from comment #87)
> Hi Michael,
> 
> An error occurred during a connection to www.valid-ev.pki.admin.ch. 
> 
>   - Invalid OCSP signing certificate in OCSP response. 
>   - Error code: SEC_ERROR_OCSP_INVALID_SIGNING_CERT
> 
> Also got errors when running
> https://certificate.revocationcheck.com/www.valid-ev.pki.admin.ch
>   - OCSP signing certificate has expired 645h44m50.63683153s ago
>   - OCSP signing certificate expires before NextUpdate
> 
> Please help to check and fix, thanks!
> 
> 
> Kind Regards,
> Aaron

Comment 89

[michael.vonniederhaeusern]

Hi Aaron

The ov test site has been taken offline because we are adding a new SubCA to our structure. An incompatibility with the QuoVadis RootSigning, that we had to make on the Public Trust CA 02 to continue operation until inclusion, made it necessary to create an additional Issuing CA (Public Trust CA 03). The ov test site will be online again as soon as the new structure is ready (within the next week) and added to our audit scope.

Best regards,
Michael

(In reply to Aaron Wu from comment #86)
> Hi Michael,
> 
> We are proceeding your request and re-verifying the data you provided before
> public discussion.
> 
> As BR Self Assessment you provided, these are the test sites: 
> 
> - VALID https://www.valid-ov.pki.admin.ch
> - REVOKED https://www.revoked-ov.pki.admin.ch
> - EXPIRED https://www.expired-ov.pki.admin.ch
> 
> It seems server not found for those sites above.
> 
> - VALID https://www.valid-ev.pki.admin.ch
> - REVOKED https://www.revoked-ev.pki.admin.ch
> - EXPIRED https://www.expired-ev.pki.admin.ch
> 
> Please also confirm those EV SSL above is correct, then I will make update
> in Salesforce.
> 
> 
> Thanks,
> Aaron

Comment 90

[Aaron Wu]

(In reply to michael.vonniederhaeusern from comment #89)
> Hi Aaron
> 
> The ov test site has been taken offline because we are adding a new SubCA to
> our structure. An incompatibility with the QuoVadis RootSigning, that we had
> to make on the Public Trust CA 02 to continue operation until inclusion,
> made it necessary to create an additional Issuing CA (Public Trust CA 03).
> The ov test site will be online again as soon as the new structure is ready
> (within the next week) and added to our audit scope.

Understood, thanks for your information regarding OV.

For EV, please also reply as comment#87 above.

> 
> Best regards,
> Michael
> 
> (In reply to Aaron Wu from comment #86)
> > Hi Michael,
> > 
> > We are proceeding your request and re-verifying the data you provided before
> > public discussion.
> > 
> > As BR Self Assessment you provided, these are the test sites: 
> > 
> > - VALID https://www.valid-ov.pki.admin.ch
> > - REVOKED https://www.revoked-ov.pki.admin.ch
> > - EXPIRED https://www.expired-ov.pki.admin.ch
> > 
> > It seems server not found for those sites above.
> > 
> > - VALID https://www.valid-ev.pki.admin.ch
> > - REVOKED https://www.revoked-ev.pki.admin.ch
> > - EXPIRED https://www.expired-ev.pki.admin.ch
> > 
> > Please also confirm those EV SSL above is correct, then I will make update
> > in Salesforce.
> > 
> > 
> > Thanks,
> > Aaron

Comment 91

[Aaron Wu]

Attachment: CAInformation_SwissBit_Final.pdf

Comment 92

[Aaron Wu]

I am now opening the public discussion period for the request from Swiss Government is to include the “Swiss Government Root CA III” root certificate, turn on the Websites trust bit, and enable EV treatment.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Swiss Government root inclusion request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Thanks,
Aaron

Comment 93

[Wayne Thayer]

Placing this discussion on hold pending:
1. Updated audit statement specifying the audit period.
2. Updated CPS including CAA information, BR compliance statement, and clearer specification of the domain validation procedures that are in use.

Comment 94

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 95

[Wayne Thayer]

Michael: This request has been awaiting updates from the CA for one and a half years now. Can this request be cancelled? If not, when will the updates requested in comment 93 be completed?

Comment 96

[Kathleen Wilson]

I am closing this bug due to inactivity. The CA may create a new Bugzilla Bug when they are ready to try again.
https://wiki.mozilla.org/CA/Application_Process