Add WISeKey commercial CA cert to builtin trusted CA list

RESOLVED FIXED

Status

task
P2
normal
RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: mbesson, Assigned: hecker)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Approved)

Attachments

(3 attachments)

Reporter

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

WISeKey operates the CertifyID Trust Service. The CertifyID Trust Service is ideal for enterprises, public service organizations, and even governments that wish to provide trusted certificates to their members and Employees. 

The WISeKey CertifyID service allows customers to incorporate their certification authority (CA), whether new or existing, into the CertifyID Trust Network. Their CA thus becomes part of the CertifyID trust community, and the end-entity digital certificates can be used within applications that trust the CertifyID Root CAs. Using this service, organizations can federate trust between suppliers, partners and other members, by issuing interoperable CertifyID trusted certificates and thus create and extend secure relationships beyond the enterprise perimeter and enable secure communications, document signing, e-mail and other services between enterprises.

CertifyID chained certificates that are part of the CertifyID trust community are interoperable and trusted by all applications that trust the CertifyID Root certificate.

 

Objective of our Root CA:

The objective of the Root CA is to issue Policy CA digital certificates. The Policy CAs are operated by WISeKey and its Affiliates and will issue digital certificates to Issuing CAs belonging to customers joining the OISTE WISeKey Trust Network. These customers will follow the guidelines of the Root CPS and subordinate documents through legally binding contract chains. The Issuing CAs will issue digital certificates to users and devices. WISeKey and its Affiliates may also operate CAs that issue certificates to end users and devices. 



Company details:

WISeKey SA (OISTE WISeKey Global Root GA CA)
route de Pré-Bois 29
P.O. Box 885
CH-1215 Geneva 15
Switzerland 

Phone:  +41 22 594 3000
 
Fax:  +41 22 594 3001
 
www.wisekey.com

 

Contact details:

Juan Avellán (Head Legal Counsel) - mail: javellan@wisekey.com - telephone: 0041 - 0225943004

Kevin Blackman (Chief Technology Officer) - mail: kblackma@wisekey.com  - telephone: 0041 - 0225943010 

 

Roots and Certificates to submit:
 
We would like to submit 1 Root CA certificate: Root Certificate

 

OISTE WISeKey Global Root GA 
Thumbprint: 59 22 a1 e1 5a ea 16 35 21 f8 98 39 6a 46 46 b0 44 1b 0f a9
Valid From: 11th December 2005
Valid To: 11th December 2037 

 

Attached to this RootCA the following Subordinate CAs exist:

WISeKey CertifyID Standard G1 CA
Thumbprint: 9d 72 1a 47 cb ca cd d7 fe 10 de a0 6c eb 3c 99 21 6d 46 15
Valid From: 23rd December 2005
Valid To: 23rd December 2020 

WISeKey CertifyID Advanced G1 CA
Thumbprint: e0 ed d3 16 54 43 d1 91 f1 b7 8a 83 c1 77 c3 7a 41 82 34 23
Valid From: 11th December 2005
Valid To: 11th December 2020 

WISeKey CertifyID Qualified G1 CA
Thumbprint: bd 59 c8 b9 e2 76 cc 0e ec ef 03 26 3b a6 63 c1 7d ae fa 98
Valid From : 17th October 2006
Valid To : 21th October 2021

WISeKey CertifyID Standard Services CA 1 
Thumbprint: e0 ed d3 16 54 43 d1 91 f1 b7 8a 83 c1 77 c3 7a 41 82 34 23
Valid From: 10th February 2006
Valid To: 10th February 2013 

WISeKey CertifyID Advanced Services CA 
Thumbprint: 185 e1 a3 a0 37 37 64 f1 d9 f6 b9 3b 7e 71 5c 13 4b 7c 8d 65
Valid From: 18th January 2006
Valid To: 18th January 2013 

WISeKey CertifyID Qualified Services CA
Thumbprint 49 20 7f c5 4e 00 d9 cb 44 36 90 74 75 02 b2 3b bb b2 0b 16
Valid From: 27th October 2006
Valid To: October 27th, 2013




Key Usages Required: 

SSL-enabled servers, 
digitally-signed and/or encrypted email. 
digitally-signed executable code objects;
Identity Validation Process:

 

To validate the identity of a Policy Certification Authority (a Subordinate CA immediately under the Root CA)  the following elements are validated:

A) An applicant’s identity and capacity to provide Policy CA services within the WISeKey PKI is determined from the moment of initial contact and thereafter during the process of negotiating and establishing an Affiliate Certification Authority. Such process includes: 

A.1) high-level management contacts between WISeKey and the applicant; 
A.2) a visit by WISeKey staff to the premises of the applicant; 
A.3) review of the originals or certified copies of the following documents, where applicable: 

A.3.1) The certificate of incorporation of the legal entity or other similarly reliable document; 
A.3.2) The memorandum and articles of association of the legal entity; and 
A.3.3) The number of registration (in the trade registry or other similar register) of the legal entity. 
A.3.4) If a governmental or public entity, an official letter by the superior governmental entity under which the applicant operates indicating its support and the authority of the applicant to provide ACA services. 

A.4) Verification of the following facts: 

A.4.1) The full legal name and postal address of the entity, and 
A.4.2) The identity and authority of the natural person(s) with the mandate to represent the applicant. 

B) The legal representatives of the legal entities applying to become an Policy Certification Authority are subject to a face-to-face identification procedure in accordance with the following general rules:
 
B.1) Provision of sufficient proof of the person’s authority within the legal entity that is applying to become a Policy Certification Authority (e.g. share-holders meeting resolutions, board-meeting minutes, or official letter or publication by a public entity); 
B.2) Provision of at least two pieces of identity in original form or as certified copies (which may vary from jurisdiction to jurisdiction) such as an official document or any document from a reputable source, which bears a photograph and a signature. This verification shall also include, where available, cross-referencing such documents with the personal identification number, social security or similar numbers as issued by a reputable source, where available. 
B.3) The identification procedure may involve: 

B.3.1) verification of the signature; 
B.3.2) examination of a possible anomaly in the photograph; 
B.3.3) verification that the documents presented do not show any sign of alteration. 

C) The technical solution that comprises the Policy CA must adhere to the technical requirements that are described within the Root CPS, and would require at minimum: 
c.1) The use of a Common Criteria evaluated Operating System, and Certificate Services components; 

C.2) The use of FIPS-140-2 Level 2 or higher accredited hardware security module. 



The physical security and operating environment controls must also meet the requirements described in the Root CA CPS. The entire installation must audited by WISeKey SA, OISTE, or a designated authorized representative.

 

The issuance of certificates for customer Issuing CAs, is governed by the Policy CA certification practice statements.

 

Pointer to Certificate Practice Statement:

http://www.wisekey.com/Repository/

 

Third-party audit which WISeKey SA has undergone:

AICPA WEBTRUST - PROGRAM FOR CERTIFICATION AUTHORITIES


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Reporter

Comment 1

13 years ago
Reporter

Comment 2

13 years ago
Reporter

Comment 3

13 years ago
Priority: -- → P2
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter

Comment 5

13 years ago
Dear Gerv,

Following your request, you will find below all the information presented with the requested format.

Thanks 

Marc

______________________________________________________


Company details:
 
WISeKey SA (OISTE WISeKey Global Root GA CA)
route de Pré-Bois 29
P.O. Box 885
CH-1215 Geneva 15
Switzerland 
 
Phone:  +41 22 594 3000
 
Fax:  +41 22 594 3001
 
www.wisekey.com
 

CA Details
----------
 
CA Name: WISEKEY SA
Website: www.wisekey.com
 
WISeKey operates the CertifyID Trust Service. The CertifyID Trust Service is
ideal for enterprises, public service organizations, and even governments that
wish to provide trusted certificates to their members and Employees. 
 
The WISeKey CertifyID service allows customers to incorporate their
certification authority (CA), whether new or existing, into the CertifyID Trust
Network. Their CA thus becomes part of the CertifyID trust community, and the
end-entity digital certificates can be used within applications that trust the
CertifyID Root CAs. Using this service, organizations can federate trust
between suppliers, partners and other members, by issuing interoperable
CertifyID trusted certificates and thus create and extend secure relationships
beyond the enterprise perimeter and enable secure communications, document
signing, e-mail and other services between enterprises.
 
CertifyID chained certificates that are part of the CertifyID trust community
are interoperable and trusted by all applications that trust the CertifyID Root
certificate.
 
Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: WTE y E. Álvarez Auditores, S.L.
Auditor Website: www.webtrust.es
Audit Document URL(s): <attached>
 
Certificate Details
-------------------
 
Certificate Name:  OISTE WISeKey Global Root GA 
Summary Paragraph: 
 
The objective of the Root CA is to issue Policy CA digital certificates. The
Policy CAs are operated by WISeKey and its Affiliates and will issue digital
certificates to Issuing CAs belonging to customers joining the OISTE WISeKey
Trust Network. These customers will follow the guidelines of the Root CPS and
subordinate documents through legally binding contract chains. The Issuing CAs
will issue digital certificates to users and devices. WISeKey and its
Affiliates may also operate CAs that issue certificates to end users and
devices. 
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/owgrgaca.crt
Version: 3
SHA1 Fingerprint: 59 22 a1 e1 5a ea 16 35 21 f8 98 39 6a 46 46 b0 44 1b 0f a9
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2005-12-11
Valid To (YYYY-MM-DD): 2037-12-11
CRL HTTP URL: http://public.wisekey.com/crl/owgrgaca.crl
Class (domain-validated, identity-validated or EV): identity-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Standard G1 CA
Summary Paragraph: 
 
This Policy CA is operated by WISeKey and its Affiliates and will issue digital
certificates to Standard Issuing CAs belonging to customers joining the OISTE WISeKey
Trust Network. These customers will follow the guidelines of the Root CPS and
subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidsg1ca.crt
Version: 3
SHA1 Fingerprint: 9d 72 1a 47 cb ca cd d7 fe 10 de a0 6c eb 3c 99 21 6d 46 15
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2005-12-23
Valid To (YYYY-MM-DD): 2020-12-23
CRL HTTP URL: http://public.wisekey.com/crl/wcidsg1ca.crl
Class (domain-validated, identity-validated or EV): identity-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Advanced G1 CA
Summary Paragraph: 
 
This Policy CA is operated by WISeKey and its Affiliates and will issue digital
certificates to Advanced  Issuing CAs belonging to customers joining the OISTE WISeKey
Trust Network. These customers will follow the guidelines of the Root CPS and
subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidag1ca.crt
Version: 3
SHA1 Fingerprint: e0 ed d3 16 54 43 d1 91 f1 b7 8a 83 c1 77 c3 7a 41 82 34 23
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2005-12-11
Valid To (YYYY-MM-DD): 2020-12-11
CRL HTTP URL: http://public.wisekey.com/crl/wcidag1ca.crl
Class (domain-validated, identity-validated or EV): identity-validated 
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Qualified G1 CA
Summary Paragraph: 
 
This Policy CA is operated by WISeKey and its Affiliates and will issue digital
certificates to Qualified Issuing CAs belonging to customers joining the OISTE WISeKey
Trust Network. These customers will follow the guidelines of the Root CPS and
subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidqg1ca.crt
Version: 3
SHA1 Fingerprint: bd 59 c8 b9 e2 76 cc 0e ec ef 03 26 3b a6 63 c1 7d ae fa 98
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-10-17
Valid To (YYYY-MM-DD): 2021-10-21
CRL HTTP URL: http://public.wisekey.com/crl/wcidqg1ca.crl
Class (domain-validated, identity-validated or EV): identity-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Standard Services CA 1 
Summary Paragraph: 
 
This issuing CA will issue digital certificates to standard users, verifying the validity of the email address within the certificate.
These final users will follow the guidelines of the Root CPS and subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidssca1.crt
Version: 3
SHA1 Fingerprint: e0 ed d3 16 54 43 d1 91 f1 b7 8a 83 c1 77 c3 7a 41 82 34 23
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-02-10
Valid To (YYYY-MM-DD): 2013-02-10
CRL HTTP URL: http://public.wisekey.com/crl/wcidssca1.crl
Class (domain-validated, identity-validated or EV): identity-validated and domain-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Advanced Services CA 
Summary Paragraph: 
 
This issuing CA will issue digital certificates to advanced users, verifying the identity of the user as described in the CPS.
These final users will follow the guidelines of the Root CPS and subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidasca1.crt
Version: 3
SHA1 Fingerprint: 185 e1 a3 a0 37 37 64 f1 d9 f6 b9 3b 7e 71 5c 13 4b 7c 8d 65
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-01-18
Valid To (YYYY-MM-DD):  2013-01-18
CRL HTTP URL: http://public.wisekey.com/crl/wcidasca1.crl
Class (domain-validated, identity-validated or EV): identity-validated and domain-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
Certificate Details
-------------------
 
Certificate Name:  WISeKey CertifyID Qualified Services CA 
Summary Paragraph: 
 
This issuing CA will issue digital certificates to qualified users, verifying the identity of the user as described in the CPS.
These final users will follow the guidelines of the Root CPS and subordinate documents through legally binding contract chains.
 
Certificate HTTP URL (on CA website): http://public.wisekey.com/crt/wcidqsca1.crt
Version: 3
SHA1 Fingerprint: 49 20 7f c5 4e 00 d9 cb 44 36 90 74 75 02 b2 3b bb b2 0b 163
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-10-27
Valid To (YYYY-MM-DD): 2013-10-27
CRL HTTP URL: http://public.wisekey.com/crt/wcidqsca1.crt
Class (domain-validated, identity-validated or EV): identity-validated and domain-validated
CPS URL: http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
Requested Trust Indicators (email and/or SSL and/or code): email and SSL
 
 
Reporter

Comment 6

12 years ago
Following Gerv request, we have posted the auditor report on our website

http://www.wisekey.com/NR/rdonlyres/B75518BD-4075-4252-9BF5-9CA4DDDC73CA/0/WebTrustReport.pdf

Thank you. But is it not available from the WebTrust site, for example like this one:
https://cert.webtrust.org/ViewSeal?id=522
? Or is there some reason why your WebTrust audit is not official? (That may not be a problem, I just want to understand the situation.)

Anyway, 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/
(It may take an hour or two to appear.)

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
Reporter

Comment 8

12 years ago
Despite the audit being undertaken by an accredited AICPA Webtrust auditor and having passed the Webtrust audit, we decided not to purchase the AICPA WebTrust seal during the first audit  because our Policy Approval Authority did not deem it necessary for the purposes of our trust model. 

This means that we aren't on their site. 

Our Policy Approval Authority is currently revising the situation and is prepared to approve the purchase of the seal on our next audit renewal which will take place in two months.

All information for our CA is correct and could therefore be turned to "green".

The "marketing" summary has been included as an introduction to my initial post.

Thanks for your support.

Marc
Just so you know, we don't actually require you to have the seal.

I will mark your CA as green soon, and add you to the queue for evaluation.

Gerv
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
I have begun this evaluation, and have some questions:

- The only CP/CPS document you have offered for review is:
http://www.wisekey.com/NR/rdonlyres/2591F1F6-4E8D-4648-B78D-0DE6DB1B1EA2/0/OISTEWISEKEYROOTCPS101Jan162007.pdf
This document does not, as far as I can see, say anything about the following topics:

- Who you issue your sub-CA certificates to
- What restrictions, if any, are placed on the certificates issued by those sub-CAs
- What validation or vetting steps are contractually required for end entity certificate issuance, if any

Do you have a document which answers these points?

Also, your CRLs are currently issued with a yearly frequency! Any plans to make this more frequent?

Gerv
Reporter

Comment 12

12 years ago
Please find answers to your last question :

1) Who you issue your sub-CA certificates to

Any company or organization that comply with our validation rules could join our trust model (see http://www1.wisekey.com/products/Blackbox/default.aspx=


2) What restrictions, if any, are placed on the certificates issued by those
sub-CAs

All details are provided in the following document: http://www.wisekey.com/NR/rdonlyres/658D7472-9AD2-4F44-AD63-2314B13F787D/0/WD0011TECHNICALSECURITYCONTROLS.pdf


3) What validation or vetting steps are contractually required for end entity
certificate issuance, if any

Our validation steps and criteria for end entity varies according to the certificates class. Details is presented in the following document: http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf

4) Also, your CRLs are currently issued with a yearly frequency! Any plans to make this more frequent?

The yearly frequency is only for the RootCA. On the PolicyCas level the frequency is once a month, and for the IssuingCAs it's every day.


Thanks

Marc
(In reply to comment #12)
> Any company or organization that comply with our validation rules could join
> our trust model (see http://www1.wisekey.com/products/Blackbox/default.aspx=

So you permit any company who joins your trust network to issue certificates that would be trusted by Firefox if we included your root?

> All details are provided in the following document:
> http://www.wisekey.com/NR/rdonlyres/658D7472-9AD2-4F44-AD63-2314B13F787D/0/WD0011TECHNICALSECURITYCONTROLS.pdf

> Our validation steps and criteria for end entity varies according to the
> certificates class. Details is presented in the following document:
> http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf

This document says (page 11/12):

Advanced Issuing CAs in the WISeKey Certificate Services framework are typically constrained as follows:

* Server or SSL certificates, can only be issued with the organisation’s registered domains. End Entity certificates are restricted

* Client certificates e.g, authentication, email etc. can only be issued containing email addresses belonging to the organisation’s registered domains.

What does "typically" mean? And what happened to the end of the sentence in the first bullet?

How do you verify that an organisation owns the domains it claims to own?

In addition, 2.1.7 says:

In general, End Entity, or Certificate Subscriber Certificates should not contain the BasicConstraints extension. If they do contain the Basic Constraints extension then the value of cA should be set to FALSE.

It "should" be set to FALSE? Surely if anything merited a MUST, this would be it? :-)

Putting it bluntly, I'd be very wary of including your root if I thought there was any way that you were putting the ability to issue arbitrary certificates trusted by us into the hands of unaudited companies. There should be technical as well as legal constraints against this.

Gerv

Comment 14

12 years ago
Dear Gerv,
Following your request please find the responses to your questions:

QU: So you permit any company who joins your trust network to issue certificates
that would be trusted by Firefox if we included your root? 

Yes. All companies entering our network are verified and validated and as soon as their certificates, whether issued through our MPKI service, or through our subordinate signing service, are chained to our root, through Policy CAs. Thus if our Root is trusted by FireFox, so would all of our customer's certificates. We run an electronic audit service on our customer's CA installations, and we use naming constraint safeguards on our customer's CAs. Should the audit service detect suspicious activity the customer CA can be suspended. Should the customer fail their annual audit, their CA is revoked.

QU: What does "typically" mean?  

We should remove typically. It should just be "ARE CONSTRAINTED AS..." 

I used "typically" because I am referring here to NAME CONSTRAINTS. And our Data Center hosted Standard and Advanced Issuing CAs don't contain Name Constraints, because they are used by many different customer(s), who are continuously added to the service. However customers are STILL constrained to using domain names that they own, but this is done at the application level, without relying on the name constraints. It will be changed to "are constrainted as..." 

See page 15 where we further clarify that CAs at customer sites ARE constrained using extended key usage constraints.

QU: And what happened to the end of the sentence in the
first bullet? 

This is an editing typo. 

QU: How do you verify that an organisation owns the domains it claims to own? 

We have an extremely strong verification and validation process. Depending on the nature of the request and class of certificate: an organisation must submit their registration documents, we check a third party database to determine the directors, we check the signature appointing their administrator for signing power, we call the organisation to do a further check (using a 3rd party DB) etc. 

For the domain names, commercial registrar records are used. The organisation name and address must match the business incorporation papers of the organisation, or the latest data available from the Business Register. We perform a call back to verify that the administrator works with the organisation, using a telephone number found through public directory services.
If its administered by another applicant on behalf of the organisation owning the domain, then we must receive a signed letter from the organisation owning the domain granting the certificate applicant the right to use domain in their SSL certificate. 

For our signing service we are onsite or have a partner onsite to actually meet the organisation's staff. etc. Granting of domain name rights is never allowed with the subordinate signing service.

Comment: Constraints extension then the value of cA should be set to FALSE. 
You are correct this should be MUST, and it has been changed in this document. 

Gerv, we do NOT allow arbitrary certifiates to be issued by unaudited companies. Even though we always strongly verify the identity of the applicant company, we still use and apply many different constraints: technical both in the X.509 CA certificate that prevents abuse when used with compliant software, and the CA software is always compliant; legal through strong contractual agreements, and we do have extensive insurance just in case; and soon an online audit system that reports to us periodically, and the CA will be auto-suspended should we not receive the report (which goes beyond traditional requirements). All installations require extensive communication with our clients and partners, and we have our own staff if not a partner, onsite with the customer. 

If there is anything we can additionally do, we will most certainly consider it.

Kind regards,
Kevin
You said: "we use naming constraint safeguards on our customer's CAs."

This is what I was getting at. If you give a sub-CA cert to Foo Corp, but it's only allowed (by the name constraints) to issue for subdomains of foocorp.com, and Firefox will reject certificates which are not of this form when it checks the certificate chain, then I have no problem. If it's allowed to issue a valid cert for paypal.com, then that gives me the screaming heeby-jeebies. :-)

Can you confirm that you use name constraints to technically restrict all such sub-CAs to issuing certificates only for subdomains of domains which are verified to be owned by the company concerned?

Gerv

Comment 16

12 years ago
Hi Gerv,

(In reply to comment #15)
> You said: "we use naming constraint safeguards on our customer's CAs."
> This is what I was getting at. If you give a sub-CA cert to Foo Corp, but it's
> only allowed (by the name constraints) to issue for subdomains of foocorp.com,
> and Firefox will reject certificates which are not of this form when it checks
> the certificate chain, then I have no problem. If it's allowed to issue a valid
> cert for paypal.com, then that gives me the screaming heeby-jeebies. :-)
> Can you confirm that you use name constraints to technically restrict all such
> sub-CAs to issuing certificates only for subdomains of domains which are
> verified to be owned by the company concerned?
> Gerv

I can confirm that ALL of our sub-CAs that are installed at customer sites have name constraints. These name constraints always include subject distinguished name constraints. There is one existing instance where we have a customer with what we call a "Standard Plus CA", where the sub-CA certificate has name constraints, but does not have domain name constraints. This "Standard Plus" CA is only allowed to issue SMIME, and client authentication certificates, and this is enforced through enhanced key usage constraints in the Sub-CA certificate. This installation includes software that processes all requests to the CA, and performs a "bounce back email check" to ensure that the registrant is the owner of the email address, before the certificate is issued (note NOT after generation and before installation, as with some other PKI providers). Such an installation and customer also undergoes an onsite audit by OISTE / WISeKey on an annual basis, and this can be more frequent. 

Other than this one customer, all Sub-CAs issued to customer sites contain name constraints, including domain name constraints which technically restrict all such sub-CAs to issuing certificates only for subdomains of domains which are verified to be owned by the company concerned.

This has been accepted by our auditors based on the environment and controls that we place on this type of service. Please let me know if this is acceptable, if not we can change our policy accordingly and also transition this customer to our managed PKI service, for this particular CA. 

Kind regards,
Kevin
Question to WISeKey for clarification, in reply to comment 16:

So, you have one sub-CA that can issue SMIME certs for any domain name,
such as (say) gerv@mozilla.org ?  
What controls or agreements do you have in place to assure that such
SMIME certs are generated truthfully?

Comment 18

12 years ago
(In reply to comment #17)
Any such sub can can only issue certificates whose email addresses have been verified by an email validation check. the user must have access to the email account. Furthermore this is enforced contractually and through policies. Naming constraints are used that identify the registration agent that issued the certiicate e.g. "valdated by CUSTOMER NAME", such that it appears in every certificate. The installation is also audited annually. There is a contractual obligation between the ra or sub-ca and Wisekey, and the RA is assisted Wisekey  software installed with the sub-CA that verifies email address ownership before certificates are issued.
kind regards,
Kevin 
(In reply to comment #8, written in April)
> Our Policy Approval Authority is currently revising the situation and is
> prepared to approve the purchase of the seal on our next audit renewal which
> will take place in two months.

Did this happen in the end? 

(In reply to comment #16)
> This has been accepted by our auditors based on the environment and controls
> that we place on this type of service. Please let me know if this is
> acceptable, if not we can change our policy accordingly and also transition
> this customer to our managed PKI service, for this particular CA. 

I share Nelson's concern about the situation with this one particular customer. We would prefer it if you would transition them to a service where arbitrary certificate issuance is not possible. Otherwise, they would need to undergo the same audits and checks that you do.

I noted various issues and typos in your document, some of which made the meaning unclear. Is there a new version of the document available with these points clarified? I assume that the URL contains some sort of checksum, and would therefore change if the document were updated.

(In reply to comment #14)
> For the domain names, commercial registrar records are used. The organisation
> name and address must match the business incorporation papers of the
> organisation, or the latest data available from the Business Register. We
> perform a call back to verify that the administrator works with the
> organisation, using a telephone number found through public directory services.
> If its administered by another applicant on behalf of the organisation owning
> the domain, then we must receive a signed letter from the organisation owning
> the domain granting the certificate applicant the right to use domain in their
> SSL certificate. 

These checks seem sufficient; can this information be added to one of your official documents?

Gerv

Comment 20

12 years ago
(In reply to comment #19)
> (In reply to comment #8, written in April)
> > Our Policy Approval Authority is currently revising the situation and is
> > prepared to approve the purchase of the seal on our next audit renewal which
> > will take place in two months.
> Did this happen in the end? 

Yes we have obtained the seal. Our web trust report can be viewed at: https://cert.webtrust.org/ViewSeal?id=643 
Our web trust seal can be viewed at:
http://www1.wisekey.com/default.aspx (upper right)

> (In reply to comment #16)
> > This has been accepted by our auditors based on the environment and controls
> > that we place on this type of service. Please let me know if this is
> > acceptable, if not we can change our policy accordingly and also transition
> > this customer to our managed PKI service, for this particular CA. 
> I share Nelson's concern about the situation with this one particular customer.
> We would prefer it if you would transition them to a service where arbitrary
> certificate issuance is not possible. Otherwise, they would need to undergo the
> same audits and checks that you do.
> I noted various issues and typos in your document, some of which made the
> meaning unclear. Is there a new version of the document available with these
> points clarified? I assume that the URL contains some sort of checksum, and
> would therefore change if the document were updated.

After explaining your concerns, the customer has agreed to transition to the managed service. For existing certificates they have agreed only that the transition take place upon expiry of each certificate, it will thus be gradual and take place throughout this year. The no. of certificates pending expiry is small, and they have been checked for veracity.
All new certificates from this point forward, will be issued on the managed PKI service. 

We will digitally sign the PDF documents in our repository and place the signing certficate in the repository. We will also review the documents to ensure correct spelling and grammar. The errors in the previous document were noted, and I believe that they were subsequently corrected, but will double check this week to ensure so.

> (In reply to comment #14)
> > For the domain names, commercial registrar records are used. The organisation
> > name and address must match the business incorporation papers of the
> > organisation, or the latest data available from the Business Register. We
> > perform a call back to verify that the administrator works with the
> > organisation, using a telephone number found through public directory services.
> > If its administered by another applicant on behalf of the organisation owning
> > the domain, then we must receive a signed letter from the organisation owning
> > the domain granting the certificate applicant the right to use domain in their
> > SSL certificate. 
> These checks seem sufficient; can this information be added to one of your
> official documents?
> Gerv

Yes, it has been added to the following document, which has been posted to our web site:
CertifyID Identity Validation Overview [PDF]
http://www.wisekey.com/NR/rdonlyres/5E650761-E829-4622-88FD-B02122723A4D/0/CertifyIDValidationVerificationOverview.pdf

Can you please advise on what else should be done to expedite the process?

Best regards,
Kevin
Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv
Assignee: gerv → hecker

Comment 22

12 years ago
This is WISeKey's updated Web Trust Audit Report, from our auditors. It has also been digitally signed using by our legal counsel.

http://www.wisekey.com/NR/rdonlyres/B75518BD-4075-4252-9BF5-9CA4DDDC73CA/0/WebTrustReport.pdf



Assignee

Comment 23

12 years ago
Thank you proviging the alternative URL for the WebTrust report. This appears to be a duplicate of the report available from

  https://cert.webtrust.org/SealFile?seal=643&file=pdf

Is that correct?

Also, I have updated the pending certificate applications list at

  http://www.mozilla.org/projects/security/certs/pending/#WISeKey

to eliminate the information for the subordinate CAs (since all we will be including is the single root) and to add references to additional documents needed to assess how end entity certificates are issued. (Note that I just checked in these changes using CVS, so it may take an hour or more for them to show up on the www.mozilla.org site.)

Once the updated WISeKey entry appears on the live web site, could you please review it to verify that the information is correct and complete. In particular, please review the following:

1. Is the root CA's name as given ("OISTE WISeKey Global Root GA CA") the correct name, and the name you would like us to use within the Mozilla certificate database?

2. Are the documents referenced the correct documents describing your current practices? Are there any other relevant documents that we should add?

3. Are the requested "trust bits" correct? As currently listed we would recognize as valid WISeKey-related certificates for SSL/TLS web sites and S/MIME email users, but we would *not* recognize as valid any code signing certificates issued under the WISeKey hierarchy.
Status: NEW → ASSIGNED

Comment 24

12 years ago
(In reply to comment #23)
> Thank you proviging the alternative URL for the WebTrust report. This appears
> to be a duplicate of the report available from
>   https://cert.webtrust.org/SealFile?seal=643&file=pdf
> Is that correct?

Yes, correct. However the report on the WISeKey site has been digitally signed, as was requested by the previous reviewer.

> Also, I have updated the pending certificate applications list at
>   http://www.mozilla.org/projects/security/certs/pending/#WISeKey
> to eliminate the information for the subordinate CAs (since all we will be
> including is the single root) and to add references to additional documents
> needed to assess how end entity certificates are issued. (Note that I just
> checked in these changes using CVS, so it may take an hour or more for them to
> show up on the www.mozilla.org site.)
> Once the updated WISeKey entry appears on the live web site, could you please
> review it to verify that the information is correct and complete. In
> particular, please review the following:
> 1. Is the root CA's name as given ("OISTE WISeKey Global Root GA CA") the
> correct name, and the name you would like us to use within the Mozilla
> certificate database?

Yes, "OISTE WISeKey Global Root GA CA" is the correct name.

> 2. Are the documents referenced the correct documents describing your current
> practices? Are there any other relevant documents that we should add?

The listed documents pertinent. In addition the two following documents may be added if you deem necessary.

CertifyID CA Privacy Policy [PDF] http://www.wisekey.com/NR/rdonlyres/CD013104-24F9-41C0-A6C7-6DC05E4803BC/0/PrivacyPolicy10.pdf, and

CertifyID Relying Party Agreement [PDF] http://www.wisekey.com/NR/rdonlyres/3FEA75D7-1596-4124-9877-3EA228E63384/0/RelyingPartyAgreement10wksigned.pdf

> 3. Are the requested "trust bits" correct? As currently listed we would
> recognize as valid WISeKey-related certificates for SSL/TLS web sites and
> S/MIME email users, but we would *not* recognize as valid any code signing
> certificates issued under the WISeKey hierarchy.

In addition we would also like to request that the Code Signing trust bit be set, as the the Qualified CAs will be capable of issuing Code Signing certificates in the future. The Qualified CA Policy documents will be covered in our next audit, and once incorporate in the next web trust audit, we will then commence Code Signing certificate issuance. 
If this would cause a delay to the incorporate of our Root, then please continue with just SMIME and SSL/TLS trust bits.
Assignee

Comment 25

12 years ago
Thank you for confirming the information. Regarding the code signing trust bit, do you currently have information about code signing in your CPS and other documents? If not, I would prefer to wait until later to turn the code signing bit on; it is a relatively simple change to make as long as you have the new documents in place and an audit covering those documents.

Comment 26

12 years ago
(In reply to comment #25)
> Thank you for confirming the information. Regarding the code signing trust bit,
> do you currently have information about code signing in your CPS and other
> documents? If not, I would prefer to wait until later to turn the code signing
> bit on; it is a relatively simple change to make as long as you have the new
> documents in place and an audit covering those documents.

We do not currently have information about code signing in our CPS documents. It will be in the Qualified CA CPS. We therefore retract our request for the code signing bit, and will wait until later.
Assignee

Comment 27

12 years ago
I've updated the WISeKey entry in the pending certificates list to revise the summary and link to two more documents referenced above. The changes should show up on the live site in an hour or so.

  http://www.mozilla.org/projects/security/certs/pending/#WISeKey
Assignee

Comment 28

12 years ago
I've completed my review of the application of WISeKey, as per sections 1, 5 and 15 of the official Mozilla 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. The documents referenced are linked to from WISeKey's entry in the pending certificates list:

http://www.mozilla.org/projects/security/certs/pending/#WISeKey

WISeKey is a CA based in Switzerland, and supports corporations and other organizations wishing to issue certificates. It has a single root CA, the WISeKey Global Root CA. The root CA issues certificates to Policy Certification Authorities, and the Policy CAs issue certificates to Issuing Certification Authorities. The Issuing CAs then issue the end entity certificates (and are the only CAs to do so). Policy CAs and Issuing CAs fall into three different classes -- Standard, Advanced, and Qualified -- each with different levels of verification of subscribers.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by WISeKey or CAs within the hierarchy rooted at WISeKey's root CA, or of instances where WISeKey or CAs in its hierarchy have 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]. WISeKey appears to provide a service relevant to Mozilla users: As noted above, it enables its customers (both in Switzerland and elsewhere in the world) to issue certificates for their own web sites (both internal and external), email users, etc. Its policies (for the root CA and CAs within its hierarchy) are documented in the documents published on its website and listed in the entry on the pending applications list.

Section 7 [Validation]. The WISeKey root CA and the CAs within its hierarchy appear to meet the minimum requirements for subscriber verification, as follows:

* Email: For S/MIME certificates issued by the CAs within the WISeKey hierarchy, the Issuing CAs at a minimum verify the applicant's control of the associated email address referenced in the certificate (Standard class). For the Advanced and Qualified classes the Issuing CAs verify applicant identity. Issuing CAs are constrained to issue certificates within the particular domain(s) of the customer associated with the Issuing CA, after verification by WISeKey that the domain(s) are owned/controlled by the organization associated with the Issuing CA. (See the table comparing the three classes, as well as "CertifyID Identity Validation Overview, Version 1.0", section 3.1 of the "WISeKey SA Advanced Services Issuing Certification Authority Certification Practice Statement, Version 1.01" and section 2.1 of "Technical Security Controls WD0011 - Version 1.0.1".)

* SSL: For SSL certificates the Issuing CAs are constrained to issue certificates within the particular domain(s) of the customer associated with the Issuing CA, after verification by WISeKey that the domain(s) are owned/controlled by the organization associated with the Issuing CA. (See "CertifyID Identity Validation Overview, Version 1.0", section 3.1 of the "WISeKey SA Advanced Services Issuing Certification Authority Certification Practice Statement, Version 1.01", and section 2.1 of "Technical Security Controls WD0011 - Version 1.0.1".)

* Code signing: WISeKey does not currently support the issuance of code signing certificates, and at this time is not requesting that this trust bit be enabled.

Section 8-10 [Audit]. WISeKey has successfully completed a WebTrust for CAs audit and has the WebTrust seal. The auditor was WTE y E. Álvarez Auditores, S.L; the audit frequency is annual.

Section 13 [Certificate Hierarchy]. See my comments above.

Other: The Issuing CAs issue CRLs for end entity certificates on a 24-hour schedule.

Based on the above information, I intend to approve the inclusion of the WISeKey root CA certificate in NSS and thence in Firefox and other Mozilla-based products. Before I do this 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.
(In reply to comment #12)
> Please find answers to your last question :
> 
> 1) Who you issue your sub-CA certificates to
> 
> Any company or organization that comply with our validation rules could join
> our trust model (see http://www1.wisekey.com/products/Blackbox/default.aspx=
> 
> 
> 2) What restrictions, if any, are placed on the certificates issued by those
> sub-CAs
> 
> All details are provided in the following document:
> http://www.wisekey.com/NR/rdonlyres/658D7472-9AD2-4F44-AD63-2314B13F787D/0/WD0011TECHNICALSECURITYCONTROLS.pdf
> 
> 
> 3) What validation or vetting steps are contractually required for end entity
> certificate issuance, if any
> 
> Our validation steps and criteria for end entity varies according to the
> certificates class. Details is presented in the following document:
> http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf
> 
> 4) Also, your CRLs are currently issued with a yearly frequency! Any plans to
> make this more frequent?
> 
> The yearly frequency is only for the RootCA. On the PolicyCas level the
> frequency is once a month, and for the IssuingCAs it's every day.
> 
> 
> Thanks
> 
> Marc
> 

Hi Marc,

Could you provide some more information concerning the physical requirements and access regulations (if any) of the current and future sub CAs. Also what kind of electronic audit service do you deploy? Preferable provide policy requirements about the obligations. Thanks.

Comment 30

12 years ago
(In reply to comment #29)
> (In reply to comment #12)
> > Please find answers to your last question :
> > 
> > 1) Who you issue your sub-CA certificates to
> > 
> > Any company or organization that comply with our validation rules could join
> > our trust model (see http://www1.wisekey.com/products/Blackbox/default.aspx=
> > 
> > 
> > 2) What restrictions, if any, are placed on the certificates issued by those
> > sub-CAs
> > 
> > All details are provided in the following document:
> > http://www.wisekey.com/NR/rdonlyres/658D7472-9AD2-4F44-AD63-2314B13F787D/0/WD0011TECHNICALSECURITYCONTROLS.pdf
> > 
> > 
> > 3) What validation or vetting steps are contractually required for end entity
> > certificate issuance, if any
> > 
> > Our validation steps and criteria for end entity varies according to the
> > certificates class. Details is presented in the following document:
> > http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf
> > 
> > 4) Also, your CRLs are currently issued with a yearly frequency! Any plans to
> > make this more frequent?
> > 
> > The yearly frequency is only for the RootCA. On the PolicyCas level the
> > frequency is once a month, and for the IssuingCAs it's every day.
> > 
> > 
> > Thanks
> > 
> > Marc
> > 
> Hi Marc,
> Could you provide some more information concerning the physical requirements
> and access regulations (if any) of the current and future sub CAs. Also what
> kind of electronic audit service do you deploy? Preferable provide policy
> requirements about the obligations. Thanks.

Hi Eddy,

Please find the following excerpt from our installation audit guide:
Facility Requirements
The hardware and software for the CertifyID CA is maintained in a secure facility with comprehensive enforced perimeter security, physical entry controls, internal access controls, secure offices, rooms and facilities, security level segregation, protection from environmental hazards, and some of the other aspects referenced in the ISO 17799 standard. 
The physical controls that AROs are required to maintain include physical and logical access control to the equipment and systems used for such purposes and to the archives of data and documents maintained as well as protection from environmental hazards. 
The CertifyID administrator(s) shall take precautions so that no other individual has unattended and/or unauthorized access to the operational CertifyID system. The CertifyID administrator uses a smartcard containing the CertifyID administrator certificate and corresponding private key, the smartcard, when not in use, shall be secured in a lockable container accessible only by the CertifyID administrator, or otherwise protected in such a way that the smartcard always remains in the sole control of the CertifyID administrator. The lockable container should be of a strength and quality such that it deters unauthorized access. In general, such lockable container should be similar in kind to a lockable container suitable to protect high-value information of the organization.
The CertifyID CA should be placed in a room that he or she can lock when not using it. The physical security of the CertifyID computer’s environment should be of a strength and quality that deters unauthorized access, similar in kind to physical security suitable to protect high-value information of the organization.
Control Activity: Physical Access 
Physical entry control - the room in which the CertifyID CA system is located should be secured such that only authorised personnel have access and a log should be kept of entry and exit of personnel to the facility.
---------
Electronic Audit Service
The electronic audit service is designed to monitor CA activity and send a daily report to WISeKey SA. The report must be sent at least weekly. If the report is not received for one week, and no valid reason is forthcoming from the client, then the CA will be suspended. The report contains a no. of statistics such as #of issued certs, #of failed requests, #whether the failed requests were due to invalid domains, adherence to naming, key usage and extended key usage constraints, and other items of audit interest.
WISeKey also monitors our customer's CA CRL availability and validity.
Regards,
Kevin
Thanks Kevin for this information. At this stage I'm left with a few questions:

1.) I'm assuming that the "should" and "shall" words above are really meant to be "must".

2.) Why aren't the requirements concerning the restrictions, limitations and requirements placed upon such a third party explicitly part of the CP/CPS? I'd expect at least the physical requirements and issuance policy to be part of that?

3.) Are you performing site visits at those third parties in order to verify compliance?

4.) Are the computer units provided by you to such a third party limited in functionalities? How are the CA key(s) stored at such a system?

5.) And at last, your own hard and software at your facility seem to be, as expected, reasonable secured for a CA. Why aren't the same requirements placed upon third parties? Aren't the risks under certain circumstances even higher than at your own facility, specially as enforceability from your side seems to be much more difficult? What other steps (than the electronic audit service) are performed from your side?

Comment 32

12 years ago
Hi Eddy,

1) Should and Shall retain their meaning. The audit requirements vary between classes of CA that we issue. At the standard level we expect an organisation to maintain the best security that it can, that it provides to its most sensitive organisation. At the Advanced and Qualified levels the requirements increase further.
The essential difference between the levels:
Standard - constrained to issue only S/MIME certficates, under domain name consrtaints  ¦ a self-audit is required ¦ spot audits are conducted by WISeKey or an approved third party
Advanced - can issue S/MIME and SERVER AUTH certificates, , under domain name consrtaints | self-audits are required ¦ an external audit is conducted annually, including at installation 
Qualified - not domain constrainted and can issue the types of certificate approved by the auditor | self-audits are required ¦ an external audit is conducted annually, including at installation 
(Only WISeKey hosts Qualified CAs.) 

2) The issuance policy and physical requirements are further detailed in separate documents such as the ones linked to in comment #30

3) WISeKey or a third party performs site visits for CertifyID Advanced verify compliance. We currently host all CertifyID Qualified CAs within our facility, however a customer hosting a Qualified CA would have to comply with the same policy requirements under which we host Qualified CAs and would undergoe a site visit for compliance by ourselves and our appointed auditor. 
We select owners of Standard CAs for site audits, our practice policy does not mandate a site visit of every owner of a Standard CA. However in practice all but one of our Standard CAs have undergone a site visit.

4) Yes, Standard and Advanced CA systems are technically limited in functionalities, as described in technical security controls document linked to in comment #30, and further in the response to question 5). CA Keys are always stored on a HSM. To this date only FIPS 140-2 L2 or higher HSMs have been used for CA keys.

5) The hardware and software at our facility is extremely well protected. Our online Qualified CAs, and Issuing CAs are not domain constrained. We require any customer that hosts Qualified CAs MUST meet similar requirements. 

The electronic audit service is a secondary control, the primary controls are the constraints we place on the CA (within its certificate) which we believe together with our validation and issuance process reduce the risk to an acceptable level. At standard and advanced levels, a customer's CA can only issue certificates under their own domain names. The CA won't allow certificates that don't respect the consrtaints to be issued.  Therefore they have a HIGH interest to secure their CA from attack, as the CA owner is the primary organisation that would be affected from such an attack. For the CA constraints to be violated, the CA owner, its personnel, or an attacker MUST maliciously use the private key with maliciously written software other than the certified CA software to issue certificates. In the extraordinary event that this occurs, then relying PKI applications which properly interpret the constraints (e.g. all apps on Windows using CAPI for validation & Firefox) alert the user when validating an improper certificate. In the event that the CA is unavailable or down, its primarily the CA owner's business that is affected. 
I've read your statements above and all the relevant documents; there remains one contradiction in your statement above: At #1 you seem to indicate that you perform spot audits for the lowest level, however in the cidclassed.pdf document and  #2 state that no auditing is required from your side.

In any case, I'll continue the discussion at the newsgroup as indicated by Frank earlier and post to this bug again for further questions if needed. Thank you for your cooperation!

Comment 34

12 years ago
(In reply to comment #33)
> I've read your statements above and all the relevant documents; there remains
> one contradiction in your statement above: At #1 you seem to indicate that you
> perform spot audits for the lowest level, however in the cidclassed.pdf
> document and  #2 state that no auditing is required from your side.
> In any case, I'll continue the discussion at the newsgroup as indicated by
> Frank earlier and post to this bug again for further questions if needed. Thank
> you for your cooperation!

Hi Eddy, Sorry for the confusion, its due to ambiguity of the term spot audit I should have said: we select a SUBSET of CID Standard customers and perform onsite spot audits on them every year. This is an auditor control that allows us to verify at least some selected systems every year. Should we see non-conformancy and a higher level of risk that we and our auditors expect, then we can expand our audit, adjust our policies, and/or apply more controls. Thus, read literally Cidclassed.pdf, is conservatively correct. It COULD also be that every CID standard customer undergoes at least one onsite audit in their CA's lifetime. I hope this clarifies the misunderstanding. Lets continue the discussion in the newsgroup as suggested. BR, K
According to http://www.mozilla.org/projects/security/certs/pending/
as of this date, this request is in "public discussion" state
Whiteboard: Public Discussion

Comment 36

11 years ago
Please advise when this root CA certificate will be authorised for inclusion. Thank you.

Comment 37

11 years ago
I'm also intested in getting information on how long until the WISeKey Root CA certificate is included Mozilla products.

Comment 38

11 years ago
I would also like to know when this is going to be included in Mozilla. They are now in Windows and Mac OS X, is there a valid point that is preventing them to be in Mozilla?

This issue is starting to be infamous. At http://www.networkworld.com/community/node/26950 there is a blog entry titled "The strange tale of a CA and Mozilla…" about this bug. Reading through this I am starting to feel there are reasons other than technical that are delaying this.
Assignee

Comment 40

11 years ago
(In reply to comment #39)
> Due to a web site update several documents that are referred to in the thread
> of this bug report on or before February 2008 have changed locations. Please
> find the updated locations of these documents below:-

Thanks for providing us the new URLs. As far as I can tell, the WISeKey entry in the pending requests list at

http://www.mozilla.org/projects/security/certs/pending/#WISeKey

has been updated with the new URLs. (The entry doesn't include links to the privacy policy and relying party agreement, but those are not as critical to us as the CPS and related documents.)
Assignee

Comment 41

11 years ago
I've restarted the public discussion for this request. Please see the mozilla.dev.tech.crypto newsgroup for more.
Assignee

Comment 42

11 years ago
We've now completed the scheduled time for public discussion on this request. Based on my reading of the prior material for this request (e.g., in the bug and in the newsgroup) and my reading of the discussion thread for this discussion period, there were two issues of note:

First is auditing of subordinate CAs as implemented by the BlackBox product. As noted by Kevin Blackman, WISeKey now does annual onsite audits of BlackBox customers. This satisfies any concerns I might have had on the subject of audits.

Second is constraining subordinate CAs to issue certificates only within their own domain(s). My understanding from the WISeKey documents and from Kevin Blackman's comments is that WISeKey implements both contractual and technical constraints in connection with the BlackBox products. Based on comments by Eddy, Nelson, et.al., there are apparently theoretical cases where such constraints could be evaded and the evasion would not be picked up by NSS (based on NSS not checking domain constraints on CN or any other values outside of the SAN stuff).

On the WISeKey end, they could mandate use of SAN in BlackBox-issued certificates (as opposed to just including it in the default template), and from the NSS end we could disallow use of CN for storing domain names. These may be good ideas for future consideration, but I can't justify holding up this request till they get implemented.

To the best of my knowledge, all other issues are as already issued in comment #28 above, and in the interests of brevity I'll not repeat all that material.
Whiteboard: Public Discussion → Approved
Assignee

Comment 43

11 years ago
D'oh, I forgot to add: I'm formally approving this request, and will proceed to file the necessary bug against NSS to include the WISeKey root.
Assignee

Updated

11 years ago
Depends on: 467138
Assignee

Comment 44

11 years ago
Filed bug 467138 against NSS for the root CA certificate inclusion.

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED

Updated

2 years ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.