Closed Bug 577665 Opened 14 years ago Closed 12 years ago

Add Trustis FPS Root CA certificate

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: rob.horne, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: In FF16)

Attachments

(5 files, 1 obsolete file)

Initial Information Gathering Document
109.98 KB, application/pdf
Details
response to questions
35.00 KB, application/msword
Details
Completed Information Gathering Document
114.02 KB, application/pdf
Details
Trustis ETSI Verification Statement 09-04-15 SECURED.PDF
167.14 KB, application/pdf
Details
Trustis-ETSI-2016.pdf
462.24 KB, application/pdf
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
Build Identifier: 

Trustis Ltd. is one of the UK's leading authorities in Public Key
Infrastructure and digital certificates. Our Trustis FPS Root CA has just passed the WebTrust audit (see http://cert.webtrust.org/ViewSeal?id=1060), is ISO 27001 accredited and has been tScheme approved (https://www.tscheme.org/directory/trustis/index.html).

Additionally, the Trustis FPS Root CA is a current member of Microsoft's Root Certificate Program: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/rootcertprog.asp

A copy of the Trustis FPS Root CA certificate and CRL can be obtained here:

http://www.trustis.com/roots/fps/index.html

Should you require a copy of our FPS Root Certificate Policy, we can provide it
as an attachment to this request.


Reproducible: Always
This is the resubmission of bug 324126. I believe the only thing missing then was a successful WebTrust audit which has now been completed.

If you need anything else let me know asap as I would really like to get this sorted quickly.

Thanks!
Accepting this bug.  I will start the Information Gathering and Verification phase as per https://wiki.mozilla.org/CA:How_to_apply, referencing the info from bug 324126.
Severity: normal → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: This is an enhancement request to include the Trustis FPS Root CA certificate in Mozilla's built-in list of approved Root CA certificates. → Add Trustis FPS Root CA certificate
Whiteboard: Information incomplete
The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
Hi Kathleen, sorry for the delay but I'm almost ready to submit the answers to your questions. Should be in the next couple of days.
Attached file response to questions — 

    
    

    
  
Hi Kathleen, at long last I've just uploaded the response to all the questions asked on 07-21-2010.

    
    

    
  
Thank you for the information.

In regards to Organization Identity Verification, Domain Name Ownership/Control Verification, and Email Address Ownership/Control verification, you refer me to "GAF Level 2". However, I have reviewed both the Certificate Policy and the PKI Disclosure Statement, and I do not see a statement in either of them saying that GAF Level 2 or GAF Level 3 must be met in verifying these things. I don't see a link to the UK Government Authentication Framework (GAF), in either document, so I haven't reviewed the GAF and I don't yet know what GAF Level 2 and Level 3 are. Additionally, we expect CAs to include information in their CP/CPS about steps that they require RAs to take to do the verification -- it's not sufficient to just reference documents/guidelines from others.

In regards to RAs, I don't understand what the following means: "Where third party RAs conduct authentication any domain or email validation is part of those more rigorous authentication checks. We do not delegate just domain or just email validation alone to any third parties."

    
    

    
  
Hi Kathleen, 

There is no statement in the CP/CPS etc to say what level of verification is undertake as it is defined by the Issuing Authority through the enrolment requirements. As Trustis may issue certs under the FPS root to differing enrolment requirements it is not specified in the CP/CPS etc. Although in practice, certs are issued after verification to GAF level 2 or 3. Links to GAF are below:

http://www.cabinetoffice.gov.uk/media/252559/regindividualsv2.pdf
http://www.cabinetoffice.gov.uk/media/252565/registra_orgs_v2.pdf

In response to your last para, although this forms part of the authentication process it is not separated out from the remainder of the verification process. In other words, we don't farm out part of the process to a third party.

I hope this makes sense.

    
    

    
  
I see that the GAF documents address verification of identity, organization, and authority. However, the Trustis documents don't appear to actually reference the GAF documents and state that those guidelines must be followed.

Also, please see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
and
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control

The issue of needing publicly available documentation about the practices/policies in regards to verification of organization, domain name, and email address is a show stopper for us because we rely on publicly available documentation and audits of those documented processes to ascertain that the CA takes reasonable measures to confirm this information.

    
    

    
  
Hi Kathleen, 

We reference the HMG Documents and verification process in a number of formats 
locations depending on the Trustis FPS service. As FPS operates to a universal minimum standard (i.e. all services although varied MUST meet the minimum standards) it is best to look at the minimum standards document. You can find this at http://www.trustis.com/pki/fpsia/ under the link for Enrolment Requirements, or go direct to http://www.trustis.com/pki/fpsia/policy/T-0104-002-ATL-013-Trustis-FPS-Minimum-Enrolment-Requirements-V3_0.pdf

This covers all the enrolment info and I believe it addresses the points you 
raise above in that the GAF standard for verification are referenced and 
outlined  and it specifies the evidence validity and corroboration 
requirements for all aspects of enrolment including the specific points you 
make above namely email address and domain registration.

Hopefully there's no other show-stoppers alongt the way!

    
    

    
  


  

    
    

    
  
This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: Information incomplete → Information confirmed complete

    
    

    
  
Thanks for all your hard work Kathleen, much appreciated. One question I do have is now we're in the queue do you have any idea how long it takes to get to the actual discussion phase?

    
    

    
  
Please see my posting about the discussion queue that I added today in mozilla.dev.security.policy.

    
    

    
  
Hi Kathleen, a coouple of updates for you.

To get the WebTrust audit more in line with our internal audit cycle we've gone through the assessment early and have had our WebTrust renewed. The latest audit report is at: https://cert.webtrust.org/ViewSeal?id=1120

We've also been through version 2.0 of the Mozilla CA Cerificate Policy and have not found any part where we do not comply.

    
    

    
  
Thanks for sending the current audit url, and for reviewing version 2.0 of the Mozilla CA Certificate Policy. I will update my records.

    
    

    
  
Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

    
    

    
  
Hi Kathleen, in response to your request:

1) This is well underway with no sign of intrusion to date.  
2) We have no cross signed certificates.
3) We are in the process of confirming this but so far all accounts checked require 2 factor authentication.
4) We have retrospective checking in place - all certificates issued are reviewed each day. All certificate requests need manual checking and accounts capable of issuing certificates have been advised of the domains to be aware of.
5) We have no external CAs and one external RA. We are investigating the best approach to answering this.

As our answers are refined I will update this bug.

    
    

    
  
Hi Kathleen, I was wondering if the queue is likely to go back to processing one applicant every two weeks?

    
    

    
  
Rob, Thanks for your response to the CA Communication action items (Comment #19).

In regards to Comment #20, that is my goal, but it may take a little more time to get there.

    
    

    
  
It looks like this request is next in the queue for discussion. I'll plan to start the discussion in early January.

In the meantime, please provide an update to Comment 19.

    
    

    
  
Kathleen, that's great news, thanks!

Update to Comment 19:

1) We have audited our PKI and no sign of intrusion or compromise is evident. The audit also reviewed the network security controls and found no potential issues.
2) We have no cross signed certificates.
3) We can confirm that all accounts capable of directly causing certificate issuance require two factor authentication.
4) All certificate requests require manual checking and RA Operators have been advised of the domains to be aware of. Each day all certificates issued in the last 24 hours are checked against the list of domains.
5) Still under investigation but hope to have this covered by early January.

    
    

    
  


  

        Attachment #490635 -
        Attachment is obsolete: true

    
    

    
  
I am now opening the first public discussion period for this request from Trustis to add the “Trustis FPS Root CA” root certificate, and turn on the websites and email trust bits.

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

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

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

The discussion thread is called “Trustis Root Inclusion Request”

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

A representative of Trustis must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion

    
    

    
  
Hi Kathleen, a quick update for you regarding our WebTrust compliance. The audit conducted at the end of November 2011 was successful but we're still waiting on KPMG to issue the report.

    
    

    
  
Our WebTrust compliance has been recertified and the latest confirmation is at https://cert.webtrust.org/ViewSeal?id=1250

We will be answering the questions on the public discussion thread in the next day or two.

    
    

    
  
Please respond here to the recent CA Communication:
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

    
    

    
  
Here are our answers to the recent CA Communication:

1) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM. Furthermore, the contract allows us to audit the customer and we can monitor  all certificates the Sub CA issues so we can revoke any MITM certs.

2) The required statement will be added and the link sent to you.

3) We have not issued any EV SSL certificates. When we do so we plan to add these requirements to the service-specific documentation.

4) We have never used MD5; all keys in CAs or EEs are 2048.

5) We hope to have a response to this requirement with you by 03/26/12.

    
    

    
  
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “Trustis FPS Root CA” root certificate, and turn on the websites and email trust bits.

Section 4 [Technical]. I am not aware of instances where Trustis 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].  Trustis appears to provide a service relevant to Mozilla users; it is a commercial CA operating primarily in the UK and Europe.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the Certificate Policy and the Minimum Enrolment Requirements, which are in English.

http://www.trustis.com/pki/fpsia/
http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
http://www.trustis.com/pki/fpsia/policy/T-0104-002-ATL-013-Trustis-FPS-Minimum-Enrolment-Requirements-V3_0.pdf

Section 7 [Validation]. Trustis appears to meet the minimum requirements for subscriber verification, as follows:

* Email: According to the CP and the Minimum Enrolment Requirements, back contact using the declared email address and or third party corroboration is undertaken as part of the enrolment process. Certificates are not issued on the basis of email address only. Applicants must fulfil all identity verification requirements AND prove ownership of the email address to be identified in the certificate.

* SSL: According to the CP and the Minimum Enrolment Requirements, the registration data for the domain is collected from approved and/or third party public sources (WHOIS) and corroborated against the information verified as part of the individual or organisation registration submitted in the application.
Where third party or public evidence does not provide corroboration of ownership of a domain, or an organisation or individual controls a domain not registered with it. Certified written evidence of ownership/control must be provided. This is verified and/or corroborated with the registered owner of the domain.

* Code: Trustis is not requesting the Code Signing trust bit at this time.

EV Policy OID: Trustis is not requesting EV treatment at this time.

Section 15 [Certificate Hierarchy].  This root signs internally-operated Issuing CAs that sign end-entity certs. The Trustis FPS Enterprise Authority is the subCA used for issuing general SSL certificates. The Trustis DTP Issuing Authority does not issue SSL certificates. The Trustis Healthcare Issuing Authority issues SSL certificates to UK NHS facilities.

* CRL 
http://www.trustis.com/pki/fps/crl/fpsder.crl
http://www.trustis.com/pki/trustis-ssl/crl/ee.crl (NextUpdate: 24 hours)
CP section 4.4.9: CRL for end-entity certs is scheduled at least every 24 hours.

* OCSP is not currently provided

Sections 9-11 [Audit]. Trustis’ audits are performed annually by KPMG and posted on the webtrust.org website: https://cert.webtrust.org/ViewSeal?id=1250

Based on this assessment I intend to approve this request to add the “Trustis FPS Root CA” root certificate, and turn on the websites and email trust bits.
Whiteboard: In public discussion → Pending Approval

    
    

    
  
That's great news Kathleen, thanks very much for your help during this long process. 

Here's our updated response to the Feb 17 CA Communication:

1)  We don't allow the issuance of these types of certificates from any of
our sub CAs. So our response for your table is: B*

*Note Trustis does not have any Sub CAs operated by third parties but the CP permits it.

2) Our legal Dept and Policy Authority assert that our existing policy enforces this. However for clarity our Root CA PDS has been updated and can be found here http://www.trustis.com/pki/fps/policy/PKI-disclosure.htm (Formatting will be improved as soon as our web guy is back in). Our response for your table is: CP/CPS does not allow MITM usage

3) The root application we have submitted does not cover EV certificates so our response for your table is: N/A

4) We have never used MD5.  All keys in CAs are at a minimum 2048. We transitioned to 2048 bit key size for all End Entity keys some time ago. Our response for your table is: Confirmed

5) Trustis are reviewing the applicability of the CAB Forum Baseline requirements to our range of services and shall be adopting them as appropriate. So our response for your table is: IP

    
    

    
  
Thank you for the update.

Now that I have stated my intent to approve this request, I will wait a couple more days to allow for further input. Then I plan to approve the request and create the corresponding NSS bug for making the actual changes.

    
    

    
  
To the representatives of Trustis: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #30, and on behalf of Mozilla I approve this request from Trustis to include the following root certificate in Mozilla:

* Trustis FPS Root CA (websites, email)

I will file the NSS bug to effect the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS

    
  
Depends on: 742514

    
    

    
  
I have filed bug #742514 against NSS for the actual changes.

    
  
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In FF16

    
    

    
  

      
      
      
      

        Attached file
          
        Trustis-ETSI-2016.pdf
        — 
      

    


  

    
    

    
  
I exchanged email with the auditor to confirm the authenticity of the attached audit statement.

    
  
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: