Closed Bug 324126 Opened 14 years ago Closed 10 years ago

Add Trustis Root CA Certificate


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


(Not tracked)



(Reporter: bill.madell, Assigned: kwilson)




(Whiteboard: information incomplete - awaiting updated audit)


(4 files)

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

This is an enhancement request to include the Trustis FPS Root CA certificate in Mozilla's built-in list of approved Root CA certificates.

Trustis Ltd. is one of the UK's leading authorities in Public Key Infrastructure and digital certificates. Our Trustis FPS Root CA is BS7799 accredited and has been tScheme approved (

Additionally, the Trustis FPS Root CA has been audited to a WebTrust-equivalent standard and is a current member of Microsoft's Root Certificate Program:

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

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

Reproducible: Always

Steps to Reproduce:
My apologies for the delay in getting to this. I've added an entry for Trustis to my CA certificate list page (URL specified above) and have looked briefly at the information on the Trustis web site. Here are some quick initial comments and questions:

1. We haven't previously encountered tScheme, so I'll have to take a look at it and see how it relates to the existing CA criteria and audit schemes already referenced in our policy.

2. Are there links on the Trustis web site to the CPS and CP? I wasn't able to find these.

3. This presumably is addressed in the CPS or CP, but what subordinate CAs (if any) exist under the Trustis FPS root CA?
Ever confirmed: true
Here's the URL for the Trustis FPS Root Certificate Policy:

Add'l information to follow shortly.  Thx!
Awaiting feedback on document review.
Still awaiting feedback on document review.
Still awaiting feedback on documentation that we sent to you previously.  Is there anything additional that you require?
Do you require any additional information from us in order to progress this request?
My apologies for the delays in looking at this application. I'm still slogging through the Trustis document(s). I'm still a bit confused on what the Trustis PKI hierarchy looks like, but it appears to have the Trustis FPS Root CA and then multiple subordinate CAs, including Trustis FPS Enterprise Authority (aka Trustis-SSL) as the main one of interest. (I presume but have not confirmed that Trustis DTP and Trustis FPS Healthcare are also subordinates; the former appears to be a CA run for the British Chamber of Commerce, the latter a CA run for the UK National Health Service.)

On identification, the Trustis FPS Root Certificate Policy implies that subordinate CAs (technically, their RAs) do positive identification of individuals and organizations (e.g., not simply domain validation), but I need to do more reading to confirm this.

On audit, I think the main task will be relating tScheme and BS7779/ISO17779 to the documents we're most familar with, namely WebTrust, the ETSI documents, etc., to confirm that there's a reasonable equivalence, at least on the things we care about.

More later as I read more.
Yes our hierarchy is one level deep. The Trustis FPS Root supports a number of sub CAs. All operated directly by Trustis under a tScheme approved service, not all are used for SSL certificates.

Our FPS Enterprise Authority is the subCA used for issuing general SSL certificates.  The DTP Issuing Authority does not issue SSL certificates; the Trustis Healthcare Issuing Authority issues SSL certificates to UK NHS facilities.

All subCAs issuing certificates must do so in accordance with the UK Gov't Authentication Framework - Level 2. This is required for all certificates from all of our FPS subCAs be they individual or SSL. In the case of SSL, this means certs issued are what you would know of as level 3 or higher. Domains are validated but a number of other criteria relating to the organization and the individual representing the organization must also be satisfied.

This framework and the specific criteria we must comply with can be found at:

Here is a rather lengthy explanation but hopefully it will save you quite a lot of work. 
When we first took the “WebTrust equivalence” route we identified that those reviewing information for acceptance of the “equivalence” would perhaps find this a major burden, especially when being faced with standards and audit requirements with which they were not familiar. To overcome this we, in conjunction with our auditors, established an approach to be able to represent the assurance of the standards (in this case WebTrust) under which the PKI operates, but avoid a monstrous task for those reviewing things. 
This involved a detailed mapping between WebTrust and tScheme/BS7799. This was – as you might expect – a major task! The result was used as a basis for the auditors to assess which areas of our existing tScheme audit were directly comparable to WebTrust and needed some additional auditing to fulfill a fully WebTrust-acceptable audit.  

In conjunction with this, we prepared a set of Management Assertions for the FPS Root CA as normally submitted for WebTrust approval. The auditors used the existing tScheme audit complemented with activities identified from the mapping exercise to satisfy themselves that:

1)	the management assertions are being fulfilled, and 
2)	that they were happy that the audit was conducted as required by WebTrust. 

In effect, a WebTrust audit was conducted against the management assertions for Trustis FPS (which I understand Alan has sent you along with all the other documentation).  The audit established that a detailed equivalence to WebTrust exists for the operation of FPS and its audit.  

This equivalence was established specifically for Trustis FPS and the context in which it operates. The cross-mapping and other experience gained during this exercise showed there are a few areas where some accommodation was required because a direct equivalence was not trivially straightforward. This approach is now being used by tScheme and others to help establish general equivalence of the schemes. 

I should however emphasize: the documentation Alan has sent you supports the fact that Trustis FPS PKI operates to standards equivalent to WebTrust for CAs, and not the general equivalence of the two schemes.
I hope this helps.
How goes the progress with this application? Please respond.
QA Contact: ca-certificates
Priority: -- → P2
W R Madell and I are corresponding by email regarding this application, and discussing audits. However, when and if we come to an understanding on that point, this request would proceed faster if Trustis were to provide the following data in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

Some of the information may already be present in, or calculable from, data in this bug or other Mozilla-maintained documents. However, having it all in one place in a standard plain format for each request will save me a great deal of time, and help me to make everyone happier quicker. :-)

CA Details

CA Name:
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 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
Certificate HTTP URL (on CA website):
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
Requested Trust Indicators (email and/or SSL and/or code):

Thanks for your help in this matter. :-)

Bill: It's been over a month. Are you able to provide the requested information?


Hi Gerv - we've gathered all of the requested info with the exception of the audit docs.

We're currently working with the auditors in order to obtain those docs that you need.

In the meantime, is it worth posting the rest of the information - or would you prefer we wait until we have all of it?


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

Assignee: hecker → gerv
Bill: I don't mind. I can't proceed without the audit docs, so posting the rest early isn't useful to me. Feel free to do whatever's easiest.

Gerv, I've spoken with Alan; considering you'll need the audit docs before the application can be progressed, we're going to hold until we have the audit material and then submit everything at once.  I'll provide an update when we reach that stage. Rgds, Bill
Gerv, the attached PDF contains the requested information regarding our Root CA and the audit pertaining to that CA.  Rgds, Bill
I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
(Note: it may take a few hours to update.)

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.

I note the following issues/questions:

- Your CRL, is sent with the "text/plain" MIME type. It should be "application/x-pkcs7-crl". Please alter the configuration of your webserver.

- Your Webtrust Equivalent audit report is over three years old. Do you have any plans for a re-audit, or was that just a one-off?

The information in our pending list entry appears correct.

I've chased the MIME type issue on the CRL and hope to have this resolved shortly.

Regarding an update to the audit report, this response from our management:

The audit report establishes that the Trustis CAs are compliant with the WebTrust assertions declared and published within the report.
Should there be a change to the declared assertions then the acceptability of our operations (and relevant t-Scheme approvals) would have to be re-evaluated against the new assertions and the equivalence re-established.
As there has been no change to the assertions nor changes to the operational policies/procedures supporting them there is no requirement to undergo another audit. 

Routine assurance that procedures are being conducted as defined and assessed in the report is achieved via maintaining ongoing tScheme and ISO27001 approvals. These approvals require regular ongoing audit visits. 

The definition of Trustis' tScheme approval and the fact that it is current can be corroborated via the tScheme website at the URI provided in our document supporting our root submission (i.e. htttp://

The tScheme website also provides the profiles for approval. These define the criteria against which audit is conducted and approval given. If required we can send these to you.

I believe that means we don't have a "planned" re-audit, but our assertions and  operational policy/procedures (upon which the WebTrust Equivalent audit report is based) have not changed as confirmed in the tScheme & ISO27001 audits we regularly complete.


The MIME type for the CRL has been changed to "application/pkix-crl"


I have begun this evaluation, and have some questions:

- I need to verify that your procedures meet the minimum requirements in our policy, section 7. Specifically, I need to confirm that you check email address or domain ownership, as appropriate, before issuing an Email or SSL certificate. I have looked at the submitted documents (t-adm-tsc-trustis-fps-root-certificate-policy-v1.04.pdf and Trustis-Certification-Practice-Statement V1.1.pdf) and cannot find where it states that. Do you, in fact, perform those checks? Can you direct me to where it says that you do?

- Your WebTrust audit report states:

"This report is intended solely for the information and use of the Directors of Trustis Ltd regarding the procedures for the Trustis FPS CA Service and is not intended to be and should not be used by anyone other than these specified parties, without prior written approval of KPMG."

It seems to me that we would not be able to rely on this audit report as it currently stands, due to this clause. (I do note that, in the letter at the top, KPMG gave permission for the report to be circulated to Microsoft under some (undisclosed) conditions.)

- Do you have a certificate hierarchy diagram?

>>It seems to me that we would not be able to rely on this audit report as it
currently stands, due to this clause.

Can you clarify why this would be an issue for Mozilla? The more specific you can be, the better.

>>Do you have a certificate hierarchy diagram

Assuming you're after something which displays the applicable (SSL/SMIME) Intermediate Authorities which operate under the the Trustis FPS Root CA?
Well, I'm just applying common sense to the reading of the document. When we use audits to confirm the practices of a CA, we are in effect relying on that auditor's assertion about the correctness of the CA's disclosure about their business practices. The clause I refer to seems to say that, by default, we are not allowed to rely on KPMG's assessment - in other words, we can't use the audit in the way we normally do (without KPMG's written approval).

Would this be your understanding of that clause? If not, what do you think it means?  

> Assuming you're after something which displays the applicable (SSL/SMIME)
> Intermediate Authorities which operate under the the Trustis FPS Root CA?

Yes. It's not a requirement, but it's useful information.

Fair point. I've raised the issue with mgmt; the aim being to get KPMG's written approval for Mozilla to use the audit.

I'll get back to you with information/answers to all 3 points as soon as possible.

Bill: just to note: KPMG's approval would really need to be public in some way - a note on their website or something. Or perhaps it could come with instructions as to how anyone could confirm its authenticity.

With WebTrust, we know people are properly audited because the reports are on the WebTrust website. But we don't have that in this case, so there needs to be a way for anyone to independently verify it.

The principle here is that other people (perhaps other browser vendors) should have access to all the information we used to make our decision.

Thanks, Gerv - I've forwarded the above clarification to the relevant people here. Bill
Gerv -

Mgmt has provided the following answers/clarifications to your questions:

1. Minimum Requirements: 

The submission is for one of our Root CAs. Thus the policy documentation etc. covers signing of Sub CAs and certificate status information which is the only function the root is permitted to perform. 

The registration requirements for end entities are delineated in the documentation of the CAs that issue end entity certificates. The authentication requirements are always at least HMG Government Authentication Level 2, see our submission document T-TSC-FPS-ATL-FPS Root CA Summary (Mozilla) v1.0.  This is rather more restrictive than your CP requires. Even so, this is just the minimum level; we issue to much higher standards from some CAs.   Thus, specific authentication and verification varies from CA to CA with more permutations as some issue only SSL certs and others only end user personal certs. This information is given in the PDS and/or Subscriber Agreement and/or Registration Requirements (e.g .

We noticed that other applicants submitting roots had made a general declaration relating  to the standards of end entity authentication and this is why we made such a declaration in our document,  T-TSC-FPS-ATL-FPS Root CA Summary (Mozilla) v1.0. If this is not OK perhaps you can clarify what you are after.

2. Web Trust Audit:

You are correct; however, you may recall that we pointed out prior to making our submission that the restriction on the Audit Report would have to be sorted out and we would have to do so prior to making our submission. 

An application was made to KPMG to allow release of the report so you could use it. This approval was obtained prior to submission of our application and we confirmed this 24 April via email. 

KPMG admin wheels turn slow, and thus we have just received the snail mail document from them. Do you want a copy?

3. Hierarchy:

Attached is a diagram covering the model for the FPS Root and Subordinate CAs without making it over complex. Is this what you needed?

Having looked back through my old mail, I've now found the "T-TSC-FPS-ATL-FPS Root CA Summary (Mozilla) v1.0", of which you speak. Is it OK to attach a copy to this bug, for the record? Or would you like to do so, to make sure we have the right one?

Please can you provide me with a current URL for "HMG Government Authentication Level 2". (I note from your document that you say it keeps changing.)

Re point 2): My comments in comment #24 still stand. There needs to be some way that anyone can verify that KPMG are standing behind their statement, just as there is for real WebTrust audits. This could either be KPMG publishing the assertion somewhere (obscure would be fine) on their website, or it could be a phone number they could call to talk to the auditor, or some other mechanism.

I'm sure you would not accept the authenticity of an assertion solely on the basis of emailed scans of documents from the applicant. :-)

Re point 3): Yes, that's fine, thanks.

- How often do you issue CRLs for end-entity certificates? Is there a standard for this within the Trustis hierarchy?

Hi Gerv,

I've attached the summary doc as requested.  Regarding your other questions/remarks:

1) HMG Minimum Requirements for Verification can be found on the Cabinet Office's website;



2) you have a valid point; personally, I agree with the need for this document to be public.  I will speak to mgmt to determine what we can do to make it so.  I assume this particular point will delay any further progression of our application?

3) The Trustis FPS Root CA issues its CRL once a year; this CRL has a validity period of 365 days.

Issuing Authorities which are subordinate to the Trustis FPS Root CA issue CRLs at least once every 24 hours (with validity periods of 24 hours).

Re: point 2): Yes, you are correct. :-)


We've added a page to our website that provides either direct links or references to our auditors, audit reports, approvals, etc.  Please have a look and let me know if this will satisfy the Mozilla requirement to make the KPMG audit public and provide relying parties an avenue for confirming the report's authenticity.

This link can also be reached via the "audits and approvals" option on the Quick Links menu.


Thank you for that. So the idea is that I could ring +44 (0) 113 231 3000 and speak to someone who could confirm that KPMG have done a WebTrust-equivalent audit of Trustis? Who should I be asking for? Malcolm Marshall, the signatory of the KPMG letter?

Although a key problem with the KPMG audit letter you link to from that page remains: we are not allowed to rely on it... You also have not linked to the document you reference above which gives anyone permission from KPMG to rely on that letter.

On the presence of links to the 
auditors' statements is quite inobvious.  One has no reason to suspect
that those logos are anything but images.  Perhaps the page should provide
more obvious indications of the presence and purpose of those links.
RE: comment #32

Gerv - yes, that would be the idea.  I'm assuming the doc ref you mention above relates to my mgmt's statement in comment #26, item 2.  I'll chase this and get it posted to the website.

RE: comment #33

Nelson - good point, I'll add 'rollover' help text to each image to make them more obvious. 

Let me suggest adding some text that says something like "Click on any logo
for more information".  So-called rollover help is good, but unless one has
some reason to suspect that rolling over the logo will do anything, one is
not likely to try rolling the mouse cursor over the logo to see what happens.

But this is mere UI discussion, and not requisite to this bug, I think.
RE: comment #35

Fair point, Nelson. I've added the appropriate text to the page.

A note below from Alan regarding the current auditor's opinion letter and a way forward.


Dear Gerv
In response to your queries below, matters have been addressed with our auditors and thus I provide you the following feedback:
The opinion letter for us is signed by a KPMG partner - a formal position within the firm. Consequently, any queries relating to any opinion letter should be addressed to the signatory. Should the individual holding the post change, the new incumbent (or I expect - more likely - staff in his department) will have access to all relevant information and be able to respond.

We have also revisited the issue of reliance on the opinion letter. Whilst the intention was that Trustis may "use" the opinion letter - which means promulgate, etc. - the ability to rely on it is not restricted.  Clearly your interpretation of the wording is somewhat different. It has been acknowledged whilst the additional letters do help clarify the situation, they add complexity and represent a somewhat "untidy" approach. 

Thus, we have arranged with our auditors to re-issue a re-worded opinion letter to eliminate any confusion. In effect, this means the last paragraph relating to "use" by Trustis will be removed.  I trust this will make things easier and fully satisfy your concerns.

If not, could you let us know ASAP. As ever, even such minor changes as this will take some time to be administered through the "system" - perhaps a week or two. Clearly, after the very long time it has taken to get our application this far, we are keen to finalise matters as soon as possible.  We would prefer confirmation from you now that we are shooting at the right target rather than waiting until the new letter is available.
Once the new letter is with us, we will promulgate it in the prescribed location and let you know it's in place so you can finalise things.

Best Regards,

I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(


Thanks for the above. Having had some recent difficulties with vagueness over audits, we are now being very careful about what we accept. Our criteria, stated as succinctly as I can, are:

"We require an audit to one of the sets of criteria in policy section 8, performed by an auditor which meets the criteria in policy sections 9 and 10, and who is willing to state publicly, in a way verifiable by an ordinary person, that they have performed such an audit, and that you passed."

So another copy of that letter with the paragraph in question removed would probably, barely, meet that requirement - if it really was possible to ring up KPMG and ask them questions about it in order to meet the verification requirement. But far better, and easier for all concerned, is if the letter or a similar statement were hosted on KPMG's website.

Moving on, I am looking again at how Trustis meets the requirements for email and SSL issuance in section 7 of our policy. You have pointed me at the HMG criteria for certificate issuance, and say that every certificate you issue under these roots is issued to at minimum those standards. Is that right? The problem is that they only seem to go some way towards meeting the section 7 requirement.

The "registration of individuals" document says:

"Where other specific attributes are registered, documentary (or other) evidence must be adduced to associate this attribute with the registrant. For example, a letter from an ISP to a registrant confirming an email address or Web addresses."

If by "web addresses" they mean domain names, then this statement would probably do. But there is no similar language I can find in the "registration of organisations" document.

Lastly, as Nelson says, UI design is not the subject of this bug, but:

- You have used the "alt" attribute for your "rollover help", which does not produce a tooltip in Firefox. alt is alternative text, to be displayed when the image cannot be - e.g. for blind users. Please use the "title" attribute, which was invented for this purpose. If you'd tested in Firefox, you would have noticed this :-)

- Even with the "click logo for more info" text, it's not very clear what's going on. Far simpler would be a text link, something like "Audit Document" in every box. That would be entirely unambiguous and easy to understand.

Gerv - we're still awaiting a revised letter from our auditors. 

As that effectively keeps this application in its current 'holding pattern', I'll use the time to put together some comments regarding the HMG criteria v Mozilla CA policy.

I've also changed the website to use the title attribute for mouseovers.


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

Assignee: gerv → hecker
Summary: Inclusion of the Trustis Root CA Certificate in Mozilla web/mail apps → Add Trustis Root CA Certificate
According to 
as of this date, the status of this request is: Information confirmed complete	
Whiteboard: Information confirmed complete
Accepting this bug
I'm assigning this bug to Kathleen Wilson, who will be collecting information relating to the request.
Assignee: hecker → kathleen95014
I have been asked to review this request and create the InfoGathering document, which is attached.  The document summarizes info that is required, and provides background for the following questions:

1) I have reviewed all of the documents (including HMG Government Authentication Level 2 for individuals), and I could not find text stating that for SSL certificates the domain name is verified to be owned/controlled by the certificate subscriber.  Please point me to the document and section where this is stated, such that sub-CAs who issue SSL certificates have to do this verification.

2) Likewise, please point me to the document and section where it states that for email certificates, it is verified that the email account associated with the email address in the cert is owned by the certificate subscriber.

3) Please provide a url to a website (can be a test site) whose cert chains up to this root.

4) Comment #40, 2007-09-03 says: “we're still awaiting a revised letter from our auditors.”  Please provide a link to this letter, or attach here.  Note that the link provided above to the KPMG report is not working.


Answers to your questions:

1) HMG Authentication levels aside, the PKI Disclosure Statements used for each of the PKIs under this Root CA provide further detail regarding what type of data is verified.  For example, the PDS dealing with our SSL service includes the following provision: "Additional data, including declared domain names and other data items submitted as part of the certificate application are subject to independent verification..." 

Will such a statement suffice as evidence that we do verify domain names?

2) Same as above; if necessary, I will locate and post a link to a PDS covering one of our S/MIME-related PKIs.

3) The link provided in item 1 uses a SSL certificate chaining to the Trustis FPS Root CA.

4) Due to the ambiguous statement within the current letter, we are currently considering an option of accrediting this hierarchy under the relevant ETSI standard(s). After which time, we would submit that to Mozilla as audit evidence. Would this approach be acceptable to Mozilla?



In regards to #1 and #2, the statement in the PDS is not quite specific enough, because it does not state exactly what is being verified under which circumstances and how the information is being verified. We are really looking for a statement about how the domain (or email address in the case of email certs) is verified to be under the ownerhip/control of the certificate subscriber.

RE #3: Thanks.

RE #4: Do you plan to do the re-audit under ETSI using the same CPS? Or will you also be updating the CPS to add some clarifying statements as per #1 and #2?

Do you have a time-frame for the new audit?


Thanks for the feedback.  I'll speak to the internal party responsible for maintaining the PDS(s) and share your comments.  With any luck, it's a quick fix; detailed and robust verification procedures exist - it seems we simply need to quantify those in a public document such as the PDS.

Regarding the ETSI audit, yes, we would submit the same CP.  As the PDS for each unique PKI anchored with the FPS Root is incorporated by reference in the CP, I believe clarification of verification processes would remain at the PDS level.  Would that be acceptable?

In terms of ETSI audit timescales, I think we're aiming to have this complete just after the new year.  That said, if we can complete this inclusion process under the current audit regime, I would like to press ahead. However, if the reservations over the current auditor statement prevents this, it looks to me as though a new audit is the only way forward.  Do you agree or do you see things differently?



Yes, having the process clarified in the PDS, with the CP referencing the PDS and the audit including that process will be sufficient. The key is that it is a documented and audited process.

One of the requirements for inclusion is to have an audit that meets the requirements of sections 8, 9, and 10 of
and there are not supposed to be open issues noted that prevent the root from being certified.

If your current audit meets these requirements, then we can move forward with it. Otherwise we will have to wait for your new audit. Note that I cannot access the current audit via the provided link above.



Yes...someone seems to have changed a few links around without my knowledge.  

The new URL is - from there, click the KPMG logo to bring up their report.

The last paragraph of the audit report was a point of contention when Gerv was involved with this bug (see Comment #20) - this is what I was referring to in my last comment.



The audit provided above was done in 2004.  My understanding is that folks tend to object when the audits are so far out of date.

My recommendation is that we move forward with the information gathering and verification phase, so we can get everything completed pending the new audit.  However, this request will likely not enter the public discussion phase until the new audit is completed.

Given this situation and the time frame for the new audit, my recommendation would also be to update the CP or CPS to provide the text stating how the domain name is verified for ssl certs, and how the email address is verified for email certs. 


This is mainly a quick comment to introduce myself. I work with Bill at Trustis, and I am taking on some of the work related to bug 324126.

In response to your last comment, we are keen that specifc statements regarding domain or email address verification are made in the PDS. This is because a number of sub-CAs use the Root CA - as covered in earlier comments by Bill regarding the existing audit.

Our plan for the new audit is:

1) Audit will take place against ETSI TS 102 042 (LCP certificate policy).

2) We need to cover the issues of domain / email address validation in the relevant PDS.

3) We need to (re)examine general statements made in the CP confirming that validation checks are made (but not how...).

Can you confirm that this is an acceptable approach for use to follow?

Dave Howse

Hi Dave,

Yes, this is a good approach.  We will wait for your updates to the PDS/CP and for the new audit. Please post links to them here when they are available.


I would like to lock down exactly what is needed of us to ensure our root submission is acceptable.

I will add a separate comment for each topic.

This comment is about the verification requirements.

As I understand it:

1) Mozilla Policy, section 7

States that the CA must take 'reasonable measures' to verify that the applicant person or organisation controls the stated email account or domain name.

2) Trustis PDS

The current Trustis PDS for certificate services (e.g. for SSL certificates) states that individuals and/or organisations will be authenticated to HMG (Government) Level 2.

The current links for the HMG requirements are:

Note that the organisation authentication includes verification of the organisation, the person representing the organisation, and the authority of that person to apply for the certificate.

The PDS then makes the statement that 'Additional data, including declared domain names and other data .... are subject to independent verification'.

3) Comment #47

You state that the PDS is not specific enough because it does not state exactly what is being verified and how it is being verified.

We could deal with the 'what is being verified' issue by stating explicitly that the email address and domains associated with the application are verified as 'belonging to' or 'being under the control of' the applicant individual and organisation.

The 'how it is verified' matter is more problematic. How verification happens is an operational matter and might not be considered as public information. However, the because of the requirements laid out in the CP and the statements made in the PDS, the responsibilities and liabilities of the IA & RA are established.

Of course, the audit will establish that the operational processes are sound and being  executed correctly.

So, subject to us stating that the email & domain ownership/control 'shall' be verified, is it sufficient to state that the ownership/control is subject to independent verification supported by audited Trustis procedures?

If not, what will we need to state to satisfy the Mozilla requirements of carrying out 'reasonable measures?

If we can agree on the approach to this matter, I will proceed to get suitable changes made to the PDS.

Hi Dave,

...subject to us stating that the email & domain ownership/control 'shall' be
verified, is it sufficient to state that the ownership/control is subject to
independent verification supported by audited Trustis procedures?

This sounds like a good approach. Would it be possible to add another sentence or two along then lines of:
Which at a minimum include verifying information in whois registries for domain names, and for email certs includes an email/download procedure with the provided email address.

Whiteboard: Information confirmed complete
Hi Kathleen,

Re: Comment #55

The reason for the general nature of the statements committing the RA to validation of the domain or email address is that the CP & PDS are mandating both the policies which are to be applied, and the required outcomes of the RA operational procedures.

Your suggested level of detail constrains the RA too much and may well not be adequate. 
For example, in the case of domain checking a number of registries may need checking, according to the actual domain name. Furthermore, the applicant might be a hosting company and will need an authorisation letter from the owner of the domain as part of the verification process.

My point is that the actual process may be quite complex; in some cases the details of the procedures might be commercially sensitive (in the sense that an RA might consider their methods superior to those of competitor RAs).

Also, as part of the quality audits, there will be an expectation of periodic improvement. Thus the (audited) procedures will change over time.

I am still hoping that the approach stated in my previous comment will be acceptable - of course, I expect to have to do  some work on the actual content of the statements in the PDS.

So I suppose the question is do you think that we can go forward on this basis? Do you see the public discussion phase as a likely stumbling block to our getting approval?

In the Mozilla CA Certificate Policy
Section 7 states:
“… for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; 
…for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;”

I believe that your approach will be sufficient, as long as the final text that you use in your updated PDS and/or CP provides sufficient information to demonstrate that “reasonable measures to verify” are taken, and that the procedures are regularly audited.

Whiteboard: information incomplete - awaiting updated audit
There has been no activity in this bug in over a year.

Is this request obsolete?

I'm open to your advice.  

The company is planning to move forward with full WebTrust for CAs and WebTrust for EV audits in the near future.  Since the wording of our current "WebTrust equivalence" audit was a major sticking point in this application process, we're optimistic that an 'official' WebTrust audit will resolve that matter.  

However, I've not been provided a concrete date on which this new audit will occur.  Given that, as well as the size and elapsed time of this stalled application, perhaps it's best to close this bug and open another when we've got all of our ducks in a row.

Would you recommend otherwise?

> perhaps it's best to close this bug and open another when we've
> got all of our ducks in a row.

Yes, I think that makes sense.  I'll close the bug now, and you can create a new request when ready.  When ready, please see the instructions for creating the root inclusion request in
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Product: → NSS
You need to log in before you can comment on or make changes to this bug.