Closed Bug 343756 Opened 18 years ago Closed 17 years ago

Request to add SwissSign root CA certificate

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hecker, Assigned: hecker)

References

(
URL
)

Details

Attachments

(8 files)

SwissSign Certificate
176.01 KB, application/pdf
Details
Management's Asssertions 2010
211.14 KB, application/pdf
Details
EV Audit Report 2010
352.08 KB, application/pdf
Details
EV Audit Statement 2012
124.72 KB, application/pdf
Details
schorpp's DGQ DE QM incentive and auditor certification
24.02 KB, image/gif
Details
EV Audit Statement 2014
239.25 KB, application/pdf
Details
KPMG_AuditConfirmation_2015.pdf
99.55 KB, application/pdf
Details
SwissSign-AuditConfirmation-2016.pdf
854.95 KB, application/pdf
Details
SwissSign is another public CA based in Switzerland. For more information about SwissSign please see the CA certificate list web page at the URL above. I'll add more information here as I read through the SwissSign CPS documents.
Status: NEW → ASSIGNED
QA Contact: ca-certificates
Frank: the SwissSign entry on your page gives audit as "TBD". Do you have a contact email address for someone at SwissSign? Gerv
New update from SwissSign: Subject: Mozilla CA Certificate Trust Store Request: SwissSign Update From: Patrick Michel <patrick.michel@swisssign.com> Date: Fri, 26 Jan 2007 17:48:51 +0100 To: certificates@mozilla.org, hecker@hecker.org Hello Mozilla Dear Frank SwissSign is now certified against ZertES (SwissDigital Signature Law) and ETSI. We like now to get into the Mozilla Trust Store. As i have seen, there is already a 'Bug' opened in Bugzilla for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=343756 Anyway here is the update. Pls. note that we have generated new CA Certificates (G2) and CP/CPS ... 1. Certificate data (or links to the data) for the CA certificate(s): > Platinum G2 Subject name: / CN=SwissSign Platinum CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Platinum G2 Root CA Validity date: Wed Oct 25 08:36:00 2006 - GMT Sat Oct 25 08:36:00 2036 > Gold G2 Subject name: / CN=SwissSign Gold CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Gold G2 Root CA Validity date: Wed Oct 25 08:30:35 2006 GMT - Sat Oct 25 08:30:35 2036 > Silver G2 Subject name: / CN=SwissSign Silver CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Silver G2 Root CA Validity date: Wed Oct 25 08:32:46 2006 GMT - Sat Oct 25 08:32:46 2036 2. for each CA certificate requested for inclusion, whether or not the CA issues certificates for each of the following purposes within the CA hierarchy associated with the CA certificate: > Platinum G2 SSL-enabled servers: yes digitally-signed and/or encrypted email: yes digitally-signed executable code objects: yes > Gold G2 SSL-enabled servers: yes digitally-signed and/or encrypted email: yes digitally-signed executable code objects: yes > Silver G2 SSL-enabled servers: yes digitally-signed and/or encrypted email: yes digitally-signed executable code objects: yes 3. a Certificate Policy and Certification Practice Statement (or links to a CP and CPS) or equivalent disclosure document(s) for the CA or CAs in question; > Platinum G2 http://repository.swisssign.com/SwissSign-Platinum-CP-CPS-R1.pdf > Gold G2 http://repository.swisssign.com/SwissSign-Gold-CP-CPS-R1.pdf > Silver G2 http://repository.swisssign.com/SwissSign-Silver-CP-CPS-R1.pdf 4. information as to how the CA has fulfilled the requirements stated above regarding its verification of certificate signing requests and its conformance to a set of acceptable operational criteria. http://www.sas.ch/de/pki_isms/pki.html See attachement. Pls. let me know if something is missing or unclear. Thanks! Best regards /Patrick -- Patrick Michel COO SwissSign AG Beethovenstrasse 49, CH-8002 Zurich http://swisssign.com
Priority: -- → P2
OS: Mac OS X → All
Patrick, There are a large number of outstanding CA requests, and it will take me some time to work through them. I can tell you that I will need the following data for each request. If some of this data is missing, the request cannot proceed. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again. This means I can make everyone happier, quicker :-) Please give data in the following format, as a *plain text comment*. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates. CA Details ---------- CA Name: Website: One Paragraph Summary of CA, including the following: - General nature (e.g., commercial, government, academic/research, nonprofit) - Primary geographical area(s) served - Number and type of subordinate CAs Audit Type (WebTrust, ETSI etc.): Auditor: Auditor Website: Audit Document URL(s): Certificate Details ------------------- (To be completed once for each certificate) Certificate Name: Summary Paragraph, including the following: - End entity certificate issuance policy, i.e. what you plan to do with the root Certificate HTTP URL (on CA website): Version: SHA1 Fingerprint: MD5 Fingerprint: Modulus Length (a.k.a. "key length"): Valid From (YYYY-MM-DD): Valid To (YYYY-MM-DD): CRL HTTP URL: OCSP URL: Class (domain-validated, identity-validated or EV): Certificate Policy URL: CPS URL: Requested Trust Indicators (email and/or SSL and/or code): Thanks for your help in this matter. :-) Gerv
I received the following information by email from SwissSign: Dear Gerv, here are the requested information: CA Name: Silver G2, Gold G2, Platinum G2 Website: http://swisssign.net One Paragraph Summary of CA, including the following: - General nature (e.g., commercial, government, academic/research, nonprofit) SwissSign AG is a commercial CSP that provides certification services for individual and corporate customers. SwissSign operates a certificate authority and a registration authority. Customers may choose to use the registration services of SwissSign and purchase single certificates. Customers may also choose to operate their own registration authority (managed PKI). - Primary geographical area(s) served SwissSign operates an Issuing CA for the Swiss Post and in this context the area is currently limited to Switzerland. Due to our limited ability to support international customers SwissSign AG also focuses on Switzerland to provide managed PKI services. Registration Services may be used internationally. - Number and type of subordinate CAs The "Platinum G2" Root CA currently has 3 subordinate CA's: "Qualified" issues certificates in accordance with ZertES (Swiss Digital Signature Law) "Personal" issues certificates for natural persons and organizations. "Swiss Post" is the issuing CA of the Swiss Post. This CA also issues certificates in accordance with Swiss tax law. Future plans for the Platinum Root include an issuing CA for machine certificates (Server). The Platinum Root also issues the certificate for the SwissSign TSA (time stamping authority) The "Gold G2" Root CA currently has 2 subordinate CA's "Personal" issues certificates for natural persons and organizations. "Server" issues certificates for machines This CA may operate customer specific Issuing CAs if and only if they fully comply with all the stipulations of the "Gold G2" CP/CPS The "Silver G2" Root CA currently has 3 subordinate CA's "Personal" issues certificates for natural persons and organizations. "Server" issues certificates for machines "Switch" is operated for a customer who issues certificates for the academic community Audit Type (WebTrust, ETSI etc.): SwissSign has been audited for Swiss Digital Signature Law. ISO 27001 and ETSI 101.456 are part of this audit. The following link shows the page of the accreditaion body in Switzerland: http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en Auditor: KPMG KPMG Klynveld Peat Marwick Goerdeler SA ISMS Zertifizierungsstelle SCES/m/ 071 Badenerstr. 172 8026 Zürich 4 SWITZERLAND Auditor Website: www.kpmg.ch Audit Document URL(s): http://www.seco.admin.ch/sas/00229/00251/00281/index.html?lang=en Certificate Details ------------------- Platinum G2 Subject name: / CN=SwissSign Platinum CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Platinum G2 Root CA Validity date: Wed Oct 25 08:36:00 2006 GMT - Sat Oct 25 08:36:00 2036 GMT Thumbprint: 56 e0 fa c0 3b 8f 18 23 55 18 e5 d3 11 ca e8 c2 43 31 ab 66 Desired extended key usage: Secure Email, Server Authentication, Client Authentication, Code Signing, Time Stamping Version: 3 CRL HTTP URL: http://crl.swisssign.net/34C58C2353ADD6DEE70092B06BFA269451CA07E4 OCSP URL: URI:http://ocsp.swisssign.net/34C58C2353ADD6DEE70092B06BFA269451CA07E4 CP /CPS URL: http://repository.swisssign.com/SwissSign-Platinum-CP-CPS-R1.pdf Requestet Trust Indicators: email, SSL, time stamping and code signing Gold G2 Subject name: / CN=SwissSign Gold CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Gold G2 Root CA Validity date: Wed Oct 25 08:30:35 2006 GMT - Sat Oct 25 08:30:35 2036 GMT Thumbprint: d8 c5 38 8a b7 30 1b 1b 6e d4 7a e6 45 25 3a 6f 9f 1a 27 61 Desired extended key usage: Secure Email, Server Authentication, Client Authentication, Code Signing Version: 3 CRL HTTP URL: http://crl.swisssign.net/0E414F33ED1FEE8DAF6A1916B706D286B253008A OCSP URL: http://ocsp.swisssign.net/0E414F33ED1FEE8DAF6A1916B706D286B253008A CP / CPS URL: http://repository.swisssign.com/SwissSign-Gold-CP-CPS-R1.pdf Requestet Trust Indicators: email, SSL and code signing Silver G2 Subject name: / CN=SwissSign Silver CA - G2 / O=SwissSign AG / C=CH Friendly name: SwissSign Silver G2 Root CA Validity date: Wed Oct 25 08:32:46 2006 GMT - Sat Oct 25 08:32:46 2036 GMT Thumbprint: 9b aa e5 9f 56 ee 21 cb 43 5a be 25 93 df a7 f0 40 d1 1d cb Desired extended key usage: Secure Email, Server Authentication, Client Authentication, Code Signing Version: 3 CRL HTTP URL: http://crl.swisssign.net/A5045DFC48B74304F31B3B90ACB036034D6AC84F OCSP URL: http://ocsp.swisssign.net/A5045DFC48B74304F31B3B90ACB036034D6AC84F CP / CPS URL: http://repository.swisssign.com/SwissSign-Silver-CP-CPS-R1.pdf Requestet Trust Indicators: email, SSL and code signing Best regards -- Mit freundlichen Grüssen Colette Steinmann SwissSign AG Beethovenstrasse 49, CH-8002 Zurich http://swisssign.com Tel: +41 43 344 88 11 Fax: +41 43 344 88 10
I have some follow-up questions: - Please can you provide simple HTTP download URLs for the three roots? I went to your site, but download links are not provided directly, and I don't want to disassemble your form-based downloading mechanism. - Many of the certificates offered for download on your site: http://swisssign.net/cgi-bin/authority/download chain back to a root called "SwissSign CA (RSA IK May 6 1999 18:00:58)" This is also the certificate offered when you choose "Download Root". Why are you not applying for the inclusion of this root? Are you moving away from using it? - What sort of SSL certificates do you issue from the roots? Domain-validated, identity/organisationally-validated, Extended Validation (EV) or some combination of the above? Thanks, Gerv
> Please can you provide simple HTTP download URLs for the three roots? The advantage of the CA download site (https://swisssign.net/cgi-bin/authority/download) is that you can choose the format and download mechanism. Anyway here are direct links to the DER encoded CA Certificates. Silver G2: http://swisssign.net/cgi-bin/authority/download/17A0CDC1E441B63A5B3BCB459DBD1CC298FA8658 Gold G2: http://swisssign.net/cgi-bin/authority/download/5B257B96A465517EB839F3C078665EE83AE7F0EE Platinum G2: http://swisssign.net/cgi-bin/authority/download/50AFCC078715476F38C5B465D1DE95AAE9DF9CCC > Why are you not applying for the inclusion of this root? Are you moving away from using it? Yes, we are moving from the "SwissSign CA (RSA IK May 6 1999 18:00:58)" root away. This because the ETSI/ZertES Certification forced us to make a new Root Key Ceremony. Another problem was the highly hierarchical design of the old 'Root' (all levels under one root) which created us some trust anchor problems with a lot of applications in the market. > What sort of SSL certificates do you issue from the roots? Domain-validated, identity/organisationally-validated, Extended Validation (EV) or some combination of the above? In the beginning the SwissPost (we are a subcompany of the SwissPost) will sell only personal certificates on a hardware crypto device under the Platinum Root. In a second step we will sell SSL certificates. It will be a combination of Domain-validated & identity/organisationally-validated. We always proof the complete subject of a certificate. The quality depends on the level you choose (silver, gold & platinum). But in any way the requester has to proof the ownership of the domain name (whois) and the organization (commercial register) Right now we don't have concrete plans to sell EV Certificates. Of course this can change ...
Wonderful. I have gathered together all the information you have provided, and placed it in the "pending" CA root certificate request list, which is here: http://www.mozilla.org/projects/security/certs/pending/ Please confirm that the information for your CA is correct, and add a comment to this bug to that effect. Once you have done that, your application will turn "green" and be ready for consideration. If your CA or certificate does not have a summary paragraph, please feel free to provide one. Note: these paragraphs are not supposed to be marketing statements :-) Gerv
confirmed! ca information are correct.
I have begun this evaluation, and have some questions: - Your ETSI audit is given by this page http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en as starting on October 30, 2006. When does it expire and need to be renewed, if ever? - Section 3.2.2 of the Platinum CPS (for example) says that a domain owner must present a signed copy of WHOIS. Given that anyone can print out the WHOIS information for a particular domain, do you in fact verify in other ways that the applicant owns the domain, and if so where does it say so in the CPS? - Platinum CPS section 6.1.7 says that subscribers may obtain code signing certificates, but the CPS nowhere says what the procedure is for issuing such certificates. Can you explain? - Please can you point me at a (test or otherwise) website using a cert signed by each of these new roots? Thanks, Gerv
Reassign all open CA bugs to me. Apologies for the bugspam. Gerv
Assignee: hecker → gerv
Status: ASSIGNED → NEW
Patrick: are you able to answer the questions posed in this bug? Gerv
Gerv, > Patrick: are you able to answer the questions posed in this bug? I have forwarded the pending issues to Melanie Raemy. She will get in contact with you soon. I will leave the company until end of month.
Hi Gerv, I'm Melanie Raemy. Since Patrick Michel has quit, I will be your new contact. As far as I have read, the 4 questions in Comment number #9 are still open. Is this correct? The first question I can answer you right now: The Attestation of the Conpliance does not actualy expire. It works as follows: We have an annual post-audit to check, if our quality did not decrease. Only if they find any problematic issues, then the compliance attestation could be taken away. But what's happening concretely, is that they will not take the attestation away, but give some instructions/tasks to be compliant again. We expect that the compliance attestation is valid as long as our company is existent. For the other questions, I have to discuss it with my collegues. But I will get in contact with you again within one week. best regards Melanie
Hi Gerv, about the domain: It is now not the case that you just print an whois record and that's fine. This would be completely useless. but in the registration form, it sais that the usage of the domain must be supported by the domain owner and the domain owner has to sign the registration form also and give a copy of the passport. so what we actually do, we check on the whois record who is the owner. we check if this owner has given the passport copy and then we check if the signature to on the registration form matches the signature an the passport copy. in chapter 3.2.2 of the cpcps, last bullet: /DC= fields will only be accepted if a printout of the WHOIS entry for the domain is included. The owner of the domain must approve the request with a handwritten personal signature in the appropriate position on the registration form and provide information as to his identity. The RA will create a high-quality copy or scan of all required supporting documentation. now, we made some investigations, what other cas do: citation: csp validates that the person enrolling for the certificate has control of the domain by requiring the person to respond to an e-mail hosted at that domain. This is also quite an elegant way and we decided to adapt this. Therefore I will extend the cpcps. I will inform you as soon as the new cpcps are released and available. Does this settle the discussion about the domain usage?
Hi Gerv, next point, code signing: You are absolutely right. It does not say much about code signing certificates.. The reason is that we did not issue them. But we want to offer them very soon. There is no reason why we shouldn't define the procedure in the cpcps now.. I will extend the cpcps with the following information: 1.Certificate profile for code signing certificates 2.Procedure of application and registration checking on our side respectively. I will inform you as soon as the new cpcps are released and available and give you the chapter numbers where to look.. Best Regards Melanie
Melanie: that all sounds excellent. I look forward to hearing from you and seeing the updated CP/CPS. Gerv
Melanie: any sign of the new CP/CPS? If it's going to take a while, I will close this bug, and we can reopen it when the new document is done. Gerv
(In reply to comment #17) > Melanie: any sign of the new CP/CPS? If it's going to take a while, I will > close this bug, and we can reopen it when the new document is done. > > Gerv > Hi Gerv, Sorry, that I haven't contact you for a while.. I have changed the CPCPS. Then I gave it someone to review.. (since it must always be approved by 2 ).. now, it is signed, but not yet published on the web. I have to wait for the next release.. The next release has been made by the developpers, but it is still being tested. Now, you know the status. Does this help you? Best Regards, Melanie
Hi Gerv, sorry, it took so long. now, this is the link for the all of the new cp/cps: http://repository.swisssign.com/index_en_G2.html this website will be online for the public at the end of the month. The CAs G2 will be productiv too at the end of the month. (as patrick pointed out on the comment #6). If you have any questions, please contact me. Best Regards, Melanie
Melanie, I've reviewed the new CP/CPSes. For the Gold and Silver roots, this is fine. As far as I can see, these roots are suitable for inclusion, based on the wording in sections 3.2.2 and 3.2.3. However, for the Platinum CPS, http://repository.swisssign.com/SwissSign-Platinum-Root-CP-CPS-R1.pdf , section 3 just says: "Identification and authentication processes for this CA and its duties/obligations are defined in non-public documents, reviewed regularly by the recognition body." I'm sure this document used to have a section 3. What happened? Lastly, do you have a certificate hierarchy diagram, showing these three roots and their subordinates? Gerv
Hi Gerv, Thank you for your quick response. I can tell you what happend: (Sorry, for the misunderstanding, I did not realise that Patrick hasn't told you before.) Under the Platinum Root CA, we have a qualified issuing CA and a personal issuing CA and a post platinum issuing CA. The CPCPS became really hard to read, since we always had to make case differentiation in each chapter. (for qualified.... else..) This made the document very long and hard to understand. We decided to split the document up and we have now a cpcps for the root and every issuing ca. Therefore: in the link in comment #19, there stands: CP/CPS of the SwissSign Platinum CA Tree The following list presents the different CP/CPS that are currently valid for the SwissSign Platinum Root CA and its subsidiary Issuing CAs. The previously unified CP/CPS has been split for ease of maintenance and to facilitate readability and understanding. * CP/CPS for SwissSign Platinum Root CA - G2. This CP/CPS governs the Root CA of the Platinum Trust tree. * CP/CPS for SwissSign Qualified Platinum CA - G2. This CP/CPS governs the issuance of qualified certificates according to Swiss digital signature law (ZertES). * CP/CPS for SwissSign Personal Platinum CA - G2. This CP/CPS governs the issuance of certificates for natural persons and organizations. * CP/CPS for Swiss Post Platinum CA - G2 (English). This CP/CPS governs the issuance of the "Postzertifikat", a product of the Swiss Post. Customers may request their Postzertifikate here . In comment #20, you cite the chapter 3 of the root. This chapter is so short, since the root does not issue certificate for clients, but only certificates of the subordinate issuing CAs, Time-stamp units etc. you will find the canges I made in the CPCPS of the qualified issuing ca and the personal issuing ca. We do have a ca hierarchy diagram. can I send this pdf to gerv@mozilla.org ? Best Regards, Melanie
Hi Gerv, a small appendix: We have to ask KPMG for their approval for every change we do within the Qualified CPCPS. Hence, it is clear that KPMG has been informed about the splitting up of the Platinum CPCPS and they approved our procedure. Best Regards, Melanie
Hi Gerv, Did you look at the CP/CPS of the Platinum Level? Do you have any questions? Do not hesitate to contact me, if you need more informations. If you do not have questions to the CP/CPS, what are the next steps? Best Regards, Melanie
Hi Melanie, Frank Hecker is taking over responsibility for the root program. I'm sure he'll be in touch soon :-) Gerv
Hi Gerv, Thank you for the information. Best Regards, Melanie
Dear Mr. Hecker, Gerv has told me, that you are taking over responsibility for the root program. I wanted to inform you, that on the 1st November 2007 our second Generation CA Hierarchy (G2) is going life. These are the CA's we requested to be in the root store. So, we are writing news for the webpage and sent notification emails to our end-users. We inform them, that we are included in the microsoft and apple root stores. Can you give me the status for the entry in the mozilla root store? As far as I know, there are no open points left. We have done some changes in the CP/CPS's after Gerv's input. Therefore, I would like to inform our end-users that we are also included in the mozilla root store. Best Regards, Melanie
Dear Mr. Hecker, Dear Gerv, we are proud to tell you that our new CA hierarchy (G2) is from now on productive. Certificates are now available to our costumers and therefore it is interesting to know for them the status of the SwissSign G2 CAs import in your trusted root store. Best Regards, Melanie Raemy
(In reply to comment #23) > Did you look at the CP/CPS of the Platinum Level? I have reviewed section 3 of the CP/CPS for the Platinum Root CA - G2, Qualified Platinum CA - G2, Personal Platinum CA - G2, and Swiss Post Platinum CA - G2. Based on my reading, it appears that the procedures outlined in the CP/CPS documents for the subordinate CAs satisfy our requirements for issuance of certificates used for secure email and for code signing. I also reviewed Section 3 of the CP/CPS for the Gold - G2 and Silver - G2 CAs. > Do you have any questions? Yes: I could not find any information in the Platinum CP/CPS documents about verification of domain name ownership for SSL server certificates. According to Gerv (comment #9) the previous version of the Platinum CP/CPS contained provisions that applied to SSL server certificates. What happened to those provisions? Also I could not find any information in the Silver CP/CPS documents about verification of domain name ownership for SSL server certificates. Based on my reading of the previous comments in this bug, along with the CP/CPS documents, I believe that the SwissSign root CAs qualify for inclusion in Mozilla as follows: * Platinum - G2 root CA: email and object signing certificates only * Gold - G2 root CA: email, object signing, SSL * Silver - G2 root CA: email and object signing certificates only Does SwissSign plan to issue SSL certificates under the Platinum and Silver hierarchies? If so, please refer me to information in the CP/CPS documents discussing verification ownership. P.S. I'm also assigning this bug to myself.
Status: NEW → ASSIGNED
(Sorry, *now* I'm assigning this bug to myself.)
Assignee: gerv → hecker
Status: ASSIGNED → NEW
I updated the entry for SwissSign in the "pending" list http://www.mozilla.org/projects/security/certs/pending/#SwissSign to reflect the current CP/CPS documents. Please verify that these are the correct and current links.
Status: NEW → ASSIGNED
(In reply to comment #28) Thank you very much for your effort. I split my answers in three parts: 1. concerning platinum: > the previous version of the Platinum CP/CPS contained > provisions that applied to SSL server certificates. What happened to those > provisions? > Does SwissSign plan to issue SSL certificates under the Platinum and Silver > hierarchies? The answer is: Since SwissSign demands that at the platinum level all keys must be generated on secure Signature creation device (SSCD), we do not think that there is a market for platinum server certificates. Therefore we removed this provicions. > * Platinum - G2 root CA: email and object signing certificates only I have a question: Does SSL only affect the server certificates? we have in the Personal Platinum end user certificates the extended key usage "client authentication". Does the mozilla web server still recognize the certificate correctly, if the SSL is not included? In this case, > * Platinum - G2 root CA: email and object signing certificates only is fine. 2. concerning Gold: > * Gold - G2 root CA: email, object signing, SSL I agree. 3. concerning Silver: > * Silver - G2 root CA: email and object signing certificates only > Does SwissSign plan to issue SSL certificates under the Platinum and Silver > hierarchies? Yes, SwissSign does issue SSL certificates under the Silver hierarchy. in the silver cpcps you have entered in this list: http://www.mozilla.org/projects/security/certs/pending/#SwissSign you see in the version control on page 2 that I have included the domain validation in Chapter 3.2.2. I have done this after Gerv's input. and Gerv reviewed the Silver CPCPS again and he has written on 2007-09-08 on Comment #20: >I've reviewed the new CP/CPSes. For the Gold and Silver roots, this is fine. Best Regards Melanie
(In reply to comment #30) > I updated the entry for SwissSign in the "pending" list > > http://www.mozilla.org/projects/security/certs/pending/#SwissSign > > to reflect the current CP/CPS documents. Please verify that these are the > correct and current links. > I have verified the CP/CPS Links: SwissSign Silver CP/CPS: correct SwissSign Gold CP/CPS: correct SwissSign Platinum CA - G2: Swiss Post Platinum CP/CPS: correct SwissSign Personal Platinum CP/CPS: correct SwissSign Qualified Platinum CP/CPS: correct SwissSign Platinum Root CP/CPS: NOT correct What you have included there is the CP/CPS before the split which includes the Qualified and Personal CAs as well. What should be there is the CP/CPS for the SwissSign Platinum Root CA: http://repository.swisssign.com/SwissSign-Platinum-Root-CP-CPS-R1.pdf You find the overview on this page: http://repository.swisssign.com/ I have other questions regarding your processes: What are the next steps: in your Pending Certificates List, there follows a step "public discussion". Do you know, how much time it takes in average until the inclusion? When we are included in the Mozilla Root Store, what does this affect? -mozilla firefox browser -mozilla thunderbird Best Regards, Melanie
(In reply to comment #31) > I have a question: > Does SSL only affect the server certificates? Yes, as far as Firefox and other Mozilla-based browsers are concerned; Firefox should be able to use SwissSign Personal Platinum end user certificates without problem, even if the SSL "trust bit" is not turned on in the NSS crypto library for the pre-loaded Platinum G2 root CA certificate. > Yes, SwissSign does issue SSL certificates under the Silver hierarchy. > in the silver cpcps you have entered in this list: > http://www.mozilla.org/projects/security/certs/pending/#SwissSign > you see in the version control on page 2 that I have included the domain > validation in Chapter 3.2.2. I'm sorry, I missed that. I will change the SwissSign entry in the "pending" list to reflect issuance of all types of certificates for Gold and Silver, but not SSL server certificates for Platinum.
(In reply to comment #32) > SwissSign Platinum Root CP/CPS: NOT correct > What you have included there is the CP/CPS before the split which includes the > Qualified and Personal CAs as well. > What should be there is the CP/CPS for the SwissSign Platinum Root CA: > http://repository.swisssign.com/SwissSign-Platinum-Root-CP-CPS-R1.pdf Thanks for the correction. I have fixed this error in the "pending" list. > I have other questions regarding your processes: > What are the next steps: in your Pending Certificates List, there follows a > step "public discussion". Do you know, how much time it takes in average until > the inclusion? The next step is for me to do one final check that all information has been provided and meets our policy requirements; I will do that today or tomorrow. If everything looks OK then I will post to our public forums my intention to approve your request, and will invite public comment. Normally I allow a comment period of two weeks, in part in order to accommodate people who may be temporarily out of the office or on vacation and who missed my initial announcement. After the comment period ends then I will officially approve the request (assuming that no one has raised relevant concerns), and will direct the NSS developers to add the SwissSign root CA data to the NSS source code. At some time after that the SwissSign root CA certificates will be included in the next version of the NSS library and then into Firefox and other products using NSS. > When we are included in the Mozilla Root Store, what does this affect? > -mozilla firefox browser > -mozilla thunderbird Yes to both of these. There are also many other products that are Mozilla-based and use the NSS root store, including the SeaMonkey browser/email client, Camino browser for Mac OS X, Flock browser, Songbird media player, Joost and Miro video players, and others. The SwissSign certificates will also be included in those products (unless for some reason the developers of those products decide to remove the CA certs -- which is unlikely).
(In reply to comment #33) > Firefox should be able to use SwissSign Personal Platinum end user > certificates without problem, even if the SSL "trust bit" is not turned on in > the NSS crypto library for the pre-loaded Platinum G2 root CA certificate. > I hope this is true. > I will change the SwissSign entry in the "pending" > list to reflect issuance of all types of certificates for Gold and Silver, but > not SSL server certificates for Platinum. > Thank you.
(In reply to comment #34) > The next step is for me to do one final check that all information has been > provided and meets our policy requirements; I will do that today or tomorrow. > If everything looks OK then I will post to our public forums my intention to > approve your request, and will invite public comment. Normally I allow a > comment period of two weeks, in part in order to accommodate people who may be > temporarily out of the office or on vacation and who missed my initial > announcement. After the comment period ends then I will officially approve the > request (assuming that no one has raised relevant concerns), and will direct > the NSS developers to add the SwissSign root CA data to the NSS source code. At > some time after that the SwissSign root CA certificates will be included in the > next version of the NSS library and then into Firefox and other products using > NSS. > Thank you for your information. Please keep me up to date with the status. Best Regards, Melanie
I've completed my review of SwissSign's application, as per sections 1, 5 and 15 of the official CA policy at: <http://www.mozilla.org/projects/security/certs/policy/>. I apologize for any delays on my part in completing the review. Here follows my assessment. If anyone sees any factual errors, please point them out. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by SwissSign, or of instances where SwissSign has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. SwissSign appears to provide a service relevant to Mozilla users: it is a commercial CA with a varied clientele, albeit confined to Switzerland for the most part. Its policies are documented in the documents published on its website and listed in the entry on the pending applications list. Section 7 [Validation]. SwissSign appears to meet the minimum requirements for subscriber verification, as follows: * Email: For certificates issued to individuals under the Silver, Gold, and Platinum CA hierachies, SwissSign verifies both identity and control of the email account associated with the email address referenced in the certificate. (See section 3.2.3 in each of the Silver CP/CPS v3.0.2, Gold CP/CPS v2.0.5, Personal Platinum CP/CPS v2.0.2, Qualified Platinum v2.0.2, and Swiss Post Platinum CP/CPS v1.0.4.) * SSL: For SSL certificates issued to organizations under the Silver and Gold CA hierachies, SwissSign validates the identity of the organization's representative and his or her authorization to request the certificate, as well as control of the associated domain. (See section 3.2.3 in each of the Silver CP/CPS v3.0.2 and Gold CP/CPS v2.0.5.) Note that SwissSign does not issue SSL certificates under the Platinum CA hierarchy. * Code: For certificates issued to individuals and organizations under the Silver, Gold, and Platinum CA hierachies, SwissSign verifies identity and (for organizations) authorization to request the certificate. (See section 3.2.3 in each of the Silver CP/CPS v3.0.2, Gold CP/CPS v2.0.5, Personal Platinum CP/CPS v2.0.2, Qualified Platinum v2.0.2, and Swiss Post Platinum CP/CPS v1.0.4.) Section 8-10 [Audit]. SwissSign has successfully completed an independent audit using the ETSI TS 101.456 criteria. The auditors were KPMG. SwissSign is subject to an annual post-audit review to (re)confirm compliance. Section 13 [Certificate Hierarchy]. SwissSign has three different root certificates, with multiple subordinates under each root, as explained in this bug and in the entry in the pending list. The multiple subordinates under each root issue different types of certificates, but the level of verification of subscribers is comparable among the various subordinate CAs associated with a given root. Other: SwissSign issues CRLs (on a 24-hour schedule) and also has an OCSP responder. Based on the above information, I intend to approve the inclusion of the three SwissSign root CAs (Platinum, Gold, and Silver) in NSS and thence in Firefox and other Mozilla-based products.. Before I do, I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period is two weeks, unless issues are brought forth that warrant further discussion.
Would it be possible to provide us with a URL or document of the audit attestation by the auditor?
(In reply to comment #38) > Would it be possible to provide us with a URL or document of > the audit attestation by the auditor? I believe that should be (is?) a requirement. Ideally it would be a URL from the auditor's web site.
Nelson: The URLs referenced are from the Swiss Accreditation Service, which (as I understand it) authorizes KPMG to perform audits for Swiss CAs. (See also below.) Melanie: There is some confusion about the auditors and the audit criteria used for SwissSign. My understanding is as follows: * The Swiss Accreditation Service is ultimately responsible for accrediting CAs to operate in Switzerland according to Swiss law. * SAS has authorized KPMG to conduct audits on its behalf, to ensure that the CAs conform to the requirements imposed by SAS. * KPMG audited SwissSign according to all of the criteria listed at http://www.seco.admin.ch/sas/00229/00251/00281/index.html?lang=en in the column "Standards", with ETSI TS 101.456 being one of these criteria. Are the statements above correct? If so, the only public evidence provided for the audit appears to be the SAS web page referenced above. Is there a separate letter from KPMG (either to SAS or SwissSign) that confirms that SwissSign passed the audit (including conforming to the ETSI TS 101.456 criteria)? If so, could you or KPMG provide us a copy of that letter that we could publish as part of the SwissSign entry on our "pending CAs" page?
(In reply to comment #40) > Melanie: There is some confusion about the auditors and the audit criteria used > for SwissSign. My understanding is as follows: > > * The Swiss Accreditation Service is ultimately responsible for accrediting CAs > to operate in Switzerland according to Swiss law. > > * SAS has authorized KPMG to conduct audits on its behalf, to ensure that the > CAs conform to the requirements imposed by SAS. > > * KPMG audited SwissSign according to all of the criteria listed at > > http://www.seco.admin.ch/sas/00229/00251/00281/index.html?lang=en > > in the column "Standards", with ETSI TS 101.456 being one of these criteria. > > Are the statements above correct? > Yes, the above statments are correct. You can view the separate letter that confirms that SwissSign passed the audit under the following link: http://repository.swisssign.com/SwissSign-Certificate_en.pdf Best Regards, Melanie Raemy
Thank you!
Confirmation of certification saved as an attachment.
Hi Melanie, I've been reading most of your CP/CPS published at http://repository.swisssign.com/ and I have a few questions concerning your inclusion request: 1.) In the Gold CP/CPS under section 3.2.2 Authentication of organization identity it says: "/DC= fields will only be accepted if a printout of the WHOIS entry for the domain is included." This implies that in case no printout is provided and/or the owner of the domain name fails to approve the request with a handwritten personal signature in the appropriate position on the registration form and provide information as to his identity, the /DC= field is omitted. Now, the DC fields of the subject line have no functions for server certificate in relation to the browser, because the browser checks the Common Name (CN) field. Can you explain why according to your CP/CPS the DC field is the relevant field for server certificates? 2.) Further in the Gold CP/CPS, section 3.2.2 it says: "SwissSign validates that the person enrolling for the certificate has control of the domain by requiring the person to respond to an e-mail hosted at that domain." As I understand it, the verification is done by requiring the person to respond to an e-mail hosted at that domain. Can you please explain how this is done exactly, because the CP/CPS currently suggests that any email address can be used for this purpose. Is this correct? 3.) The Silver CP/CPS omits any reference to domain ownership or verification at all! Going through the entire document there is no actual reference to server certificates (or whois/domain checks and validations). At http://www.mozilla.org/projects/security/certs/pending/#SwissSign and in this bug report you requested the web sites (Server) trust bits set as well.
(In reply to comment #44) Hi, > > I've been reading most of your CP/CPS published at > http://repository.swisssign.com/ and I have a few questions concerning your > inclusion request: Thank you for your interest > 3.) > > The Silver CP/CPS omits any reference to domain ownership or verification at > all! Going through the entire document there is no actual reference to server > certificates (or whois/domain checks and validations). > > At http://www.mozilla.org/projects/security/certs/pending/#SwissSign and in > this bug report you requested the web sites (Server) trust bits set as well. > in chapter 3.2.2 of SwissSign-Silver-CP-CPS-R2.pdf SwissSign validates that the person enrolling for the certificate has control of the domain by requiring the person to respond to an e-mail hosted at that domain. After Gerv's input we made some investigations how other CSP do this and we adapted this procedure. > > 2.) > > Further in the Gold CP/CPS, section 3.2.2 it says: > > "SwissSign validates that the person enrolling for the certificate has control > of the domain by requiring the person to respond to an e-mail hosted at that > domain." > > As I understand it, the verification is done by requiring the person to respond > to an e-mail hosted at that domain. Can you please explain how this is done > exactly, because the CP/CPS currently suggests that any email address can be > used for this purpose. Is this correct? > no, it is not just any. We take the email out of the whois record. Mostly it is the email adress hostmaster@domain.com (most domains have this email adress. also mozilla: hostmaster@mozilla.com) > 1.) > > In the Gold CP/CPS under section 3.2.2 Authentication of organization identity > it says: > > "/DC= fields will only be accepted if a printout of the WHOIS entry for the > domain is included." > > This implies that in case no printout is provided and/or the owner of the > domain name fails to approve the request with a handwritten personal signature > in the appropriate position on the registration form and provide information as > to his > identity, the /DC= field is omitted. > > Now, the DC fields of the subject line have no functions for server certificate > in relation to the browser, because the browser checks the Common Name (CN) > field. Can you explain why according to your CP/CPS the DC field is the > relevant field for server certificates? > It's not the case that the DC field ist the relevant field for server certificates. The domain is in the Common Name, I agree. and in chapter 3.2.2 of SwissSign-Gold-CP-CPS-R2.pdf is written: SwissSign validates that the person enrolling for the certificate has control of the domain by requiring the person to respond to an e-mail hosted at that domain. where the email adress is taken out of the whois (as explained above) So, the in the CN is the domain and the control of the domain is validated. Additionally, we wanted to say, that also in the DC you cannot write any domain, but it must be the same as on the whois that was checked for the CN. Unfortunately, as it seems, it is not well formulated. I will make a note, that this should be reformulated to clarify in the next update. Best Regards, Melanie Raemy
Excellent, Melanie! I suggest to update your CPS to make it clear that the email address is taken from the the whois records (and all alternative acceptable mail addresses as well if such are provided). It was obvious that the DC field was in correspondence with the verification performed as outlined in Gold CP/CPS, but wasn't obvious concerning the CN field. Since no DC fields are included in the certificates issued by the Silver root it confused me regarding the email verification.
(In reply to comment #46) > Excellent, Melanie! > > I suggest to update your CPS to make it clear that the email address is taken > from the the whois records (and all alternative acceptable mail addresses as > well if such are provided). > After discussing with the official domain registrar of switzerland (switch), we were informed, that they do not publish the domain email adress any more in the whois record. Therefore, I will clarify this point in the next release of CP/CPS by adding: The accepted email adresses to validate the control of the domain are hostmaster@domain and webmaster@domain. Best Regards, Melanie Raemy
Today is the last day of the two week public comment period for SwissSign's application (per comment #37). Based on comments in this bug and in themozilla.dev.tech.crypto forum, it appears that the concerns and issues raised by various people (Eddy, Nelson, et.al.) have been addressed, and are not at this point impediments to final approval of SwissSign. Therefore absent objection tomorrow (Friday November 30) I am going to officially approve inclusion of the three SwissSign root CA certificates, and proceed with the other steps needed to get the certs into NSS.
Per my comments above, I am approving the three SwissSign CA certificates for inclusion, and I've opened bug 407396 for the actual addition of the certificates to NSS.
Since bug 407396 (add certs to NSS) was resolved FIXED, I'm resolving this bug as FIXED as well.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Attached file EV Audit Report 2010 —
(In reply to Gervase Markham [:gerv] from comment #1) > Frank: the SwissSign entry on your page gives audit as "TBD". Do you have a > contact email address for someone at SwissSign? > > Gerv Public review #1: 01: CA maintainer contacts: FAILURE: 550 5.1.1 <freddy.kaiser@swisssign.com>: Recipient address rejected: User unknown 550 5.1.1 <melanie.raemy@swisssign.com>: Recipient address rejected: User unknown 550 5.1.1 <webmaster@swisssign.com>: Recipient address rejected: User unknown No acceptable communications available at this CA, only form mail "nags" and expensive hotlines. Public review #1: 02 : CA server services random test: FAILURE 4 - 2013-06-25 03:10:48 gpgsm[9783]: DBG: connection to dirmngr established 5 - 2013-06-25 03:10:48 dirmngr[9785.0] DBG: <- LOOKUP melanie.raemy@swisssign.com 5 - 2013-06-25 03:10:48 dirmngr[9785]: DBG: cmd_lookup: trying directory.swisssign.net:0 base=[default] 5 - 2013-06-25 03:10:48 dirmngr[9785]: ldap wrapper 9786 started (reader 0x7588a0) 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Verarbeiten der URL `ldap:///?userCertificate,caCertificate,x509caCert?sub?(%7C(sn%3D*melanie.raemy%40swisssign.com*)(%7C(cn%3D*melanie.raemy%40swisssign.com*)(mail%3D*melanie.raemy%40swisssign.com*)))' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Host `directory.swisssign.net' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Port 389 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: DN `' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Filter `(|(sn=*melanie.raemy@swisssign.com*)(|(cn=*melanie.raemy@swisssign.com*)(mail=*melanie.raemy@swisssign.com*)))' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Attribut `userCertificate' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Attribut `caCertificate' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Attribut `x509caCert' 5 - 2013-06-25 03:10:48 dirmngr[9785]: dirmngr_ldap[9786]: Anbindung an `directory.swisssign.net:389' fehlgeschlagen Public review #1: 03 : CA auditor's documents validation: FAILURE Electronic documents from auditors attachment 496849 [details] attachment 496851 [details] attachment 496849 [details] without valid (Swiss Signature Law) electronic signatures. ... ? y tom
http://www.kpmg.com/US/en/about/Pages/CodeOfConduct.aspx http://www.kpmg.com/US/en/about/Documents/kpmg-code-of-conduct.pdf "As individuals, we take ownership, stay informed, lead by example, consult with others, stand firm, and raise our hands when we see something that is inconsistent with our values or professional responsibilities." ? y tom
Correction (Bugzilla "usability bug" trigger'd in c54): Electronic documents from auditors https://bugzilla.mozilla.org/attachment.cgi?id=675357 https://bugzilla.mozilla.org/attachment.cgi?id=496851 without valid (Swiss Signature Law) electronic signatures. ... ? y tom
https://bugzilla.mozilla.org/attachment.cgi?id=675357 "Please do not hesitate to contact Mr. [KPMG] (+41 xxxxxx), leader of the certification body of KPMG AG (Switzerland), should you have any queries." That's very customer friendly,. but how will Mr. [KPMG] authenticate the caller on his phone?
Tom, I don't understand what the problem is that you are trying to report. I don't plan to electronically sign documents that I attach to Bugzilla bugs. I exchanged email with a contact at KPMG (@kpmg.com) to confirm the authenticity of the audit statement. I have current contact information for each CA, but I don't publish it. I do publish a general information spreadsheet for each included root certificate: http://www.mozilla.org/projects/security/certs/included/index.html
(In reply to Kathleen Wilson from comment #58) > Tom, I don't understand what the problem is that you are trying to report. I See c55,57. I'm just doing a public review probe of Your inclusion process, KPMG's and SwissSign process practices, do I need a special commercial closed source products/"secure by obscure"- auditor accreditation for this in the OSS world or what do You not understand? > don't plan to electronically sign documents that I attach to Bugzilla bugs. c55 alone requires KPMG's audit certification documents crypthographically signed by them according to suisse electronic signature law as best practice, Your're not entitled to sign documents on their behalf, are You? All PDF readers indicate no such electronic signature and so appear invalid first. > I exchanged email with a contact at KPMG (@kpmg.com) to confirm the > authenticity of the audit statement. Not publicly reviewable. Process and details (S/MIME- signature e.g.) disclosed and not published in this bug thread (Not the practice of Your predecessor/colleague?), see certificate inclusion bugs threads. > > I have current contact information for each CA, but I don't publish it. Why was this practice changed? Why is the invalid SwissSign CC contact still in this bug's CC list so SwissSign gets no more noticed about such public review issues and Bugzilla mail bounces? Why ist the KMPG contact not in the CC list after their electronic document practice has become questioned here? This could be a serious issue (for them). If Mozilla Foundation's latest policy does forbid public review by anyone, then state that publicly, please. > > I do publish a general information spreadsheet for each included root > certificate: > http://www.mozilla.org/projects/security/certs/included/index.html 1. Sorry, fails 1st random test: -> https://cert.webtrust.org/ViewSeal?id=355 Invalid domain [https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&single=true&gid=1&output=html]: please contact your practitioner. 2. http://swisssign.com/en/support/downloads/doc_download/68-zertes-certificati All PDF readers here indicate missing electronic signature. ? y tom
I would have left this at the "think about" state, but since my legitimation has been challenged by a flood of very "unhonorable" job scams in my Google spambox, I've to answer once more: 1. (In reply to Kathleen Wilson from comment #58) > Tom, I don't understand what the problem is that you are trying to report. I > don't plan to electronically sign documents that I attach to Bugzilla bugs. > I exchanged email with a contact at KPMG (@kpmg.com) to confirm the > authenticity of the audit statement. You seem to have actually exchanged mail with: $ swaks -tls -t info@kpmg.com === Trying kpmg.com.s8a1.psmtp.com:25... === Connected to kpmg.com.s8a1.psmtp.com. ... === TLS started w/ cipher AES256-SHA === TLS peer subject DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.psmtp.com" ... and not with kpmg's ("fully qualified") whois- or TLS- authenticateable domain. So the question for S/MIME- integrity and authentication of the received KPMG audit information remains unanswered and fails public peer review of Your claim at this point. 2. (In reply to Kathleen Wilson from comment #51) > Created attachment 496849 [details] > Management's Asssertions 2010 If this document has been electronically signed with a signature from the same as their own new CA they've applied for Mozilla inclusion in this document, then it had not to be accepted by Mozilla CA list maintainer and Mozilla QM head, because it would have been invalid because it would have been simply self-signed and would fail public peer and QM review. Was this the case? 3. Public answer to the job mail scammers: My QM Internal Auditor and Incentive legitimation paper is now attached here, in copy, lowest level electronically signed as "best" as KPMG's practice, and since Mozilla Foundation and Software production is OSS and open with standing calls for volunteers, I can claim to be legitimated as internal auditor and basic QM peer reviewer here. So I hereby challenge KPMG as David against Goliath: ANSWER the questions above from my first post down to here that Mozilla (QM-) leaders refused to answer, publicly, or go and have me destroyed, I'm pretty sure You, possibly backed by some Mozilla (QM-)leaders, can do that by a single phone call to the DGQ DE heads. I will never "serve the capital markets" like they and KPMG do anyway, because that "service" involvement nearly destroyed the markets and whole world economy in 2008 Financial Systems Crashes, but if DGQ insists on such a "service" and "respect" from me, I've got no more use for their accreditations and certifications, then. And whatever You may have read on Facebook and the WWW over my person (and my (suspected) virtual persons), this is NOT about politics, this is about pure IT/Software/QM and economics, even the last paragraph above.
One last point, since it's REALLY IMPORTANT for the users of PKI certificates: Since most of us live in "capital markets" where someone has to pay for any damage, and the questions I'm now raising is, who will pay for any damage introduced by any "best certified" PKI CA: Have You ever read KPMG's eg. terms & conditions for such audits? I don't even try to find it online because they will surely not publish it for good reasons, we've to wait until someone "leaks" it: You don't need a lawyer to read it, don't You? I don't: The liability and warranty terms are pretty the same as the GPL no warranty version. That means, to protect the users CAs do need a good insurance (maybe on the checklist of such audits), and have You ever read the book-thick full terms of Your own insurance contracts? If You've done this "homework" You'll will have learned none of them will pay but the users alone in the end. So in Germany we have a saying for such "insurances" and "certifications": "You can't even buy a biscuit for."
Received email from KPMG: ~~ KPMG confirms to have issued the denoted audit statement. KPMG did perform the audit from 3rd February to 28th March 2014. KPMG confirms the following listed root certificates are in scope of the conducted audit as denoted in the CP/CPS provided by SwissSign. SwissSign currently has three root certificates included in Mozilla products: 1) SwissSign Gold CA - G2 2) SwissSign Platinum CA - G2 3) SwissSign Silver CA - G2 SwissSign is requesting inclusion of the three root certificates: 1) SwissSign Gold Root CA - G3 2) SwissSign Platinum Root CA - G3 3) SwissSign Silver Root CA - G3 G3 generation comprises SHA2 family hash value application. ~~
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: