1360184 - Trustis Ltd Audit Statement 2017

Status: RESOLVED WORKSFORME

(CA Program :: CA Documents, task)

Description

[Blake Morgan]

Attachment: Secured Trustis_ETSI_Verification_Statement_30-03-17-v1.pdf

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170413192749

Comment 1

[Kathleen Wilson]

Closing this bug, but this bug may continue to be used for uploading annual audit statements for this CA.

Comment 2

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_05-04-18-v1.pdf

Please see compliant audit statement for the Trustis FPS Root CA for 2018.  tScheme apporval has been granted and we are awaiting the update of the tscheme website.

Comment 3

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_05-04-18-v3 (002).pdf

Please see updated audit statement which should satisfactorily meet the Baseline Requirements.

Comment 4

[Kathleen Wilson]

(In reply to Blake Morgan from comment #3)
> Created attachment 8967407 [details]
> Entrust (Europe) Limited_ETSI_Verification_Statement_05-04-18-v3 (002).pdf
> 
> Please see updated audit statement which should satisfactorily meet the
> Baseline Requirements.


There is only one certificate listed in the table titled:
"Trustis FPS Services operate under the following PKI Root Certificate Authorities"
and that is and intermediate cert:
SHA-1 Thumbprint: 5E5040CC818AD8C80A25C78A93A678DD8D4A5640
this corresponds to: https://crt.sh/?id=7307930

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information
"3. Distinguished Name and SHA256 fingerprint of each **root and intermediate certificate** that was in scope;"

In addition to the root cert not being in scope of the audit, this root also has other intermediate certs that do not appear to be in scope of the audit, and are not technically constrained via EKU and Name Constraints:
Chamber SimplySign TT Issuing Authority
Trustis Healthcare TT Issuing Authority
Trustis Limited - Trustis FPS TT Issuing Authority

See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#intermediate-certificates

Comment 5

[Blake Morgan]

Hello,

Apologies, I uploaded the wrong version of the audit statement. You will now receive the correct one.

Only one intermediate CA is included within the scope of the audit; Trustis Limited - Trustis FPS FF Issuing Authority.  All others are no longer in-service and there are no live Certificates associated with them.  Chamber SimplySign IA has already been decomissioned and the others are due to be scheduled for full revocation and decomissioned over the next 12 months.

Comment 6

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_v6.pdf

Compliant Audit Statement now provided.

Comment 7

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_v6.1.pdf

Comment 8

[Kathleen Wilson]

After much consideration, I added the following Case Comment to the corresponding Audit Case in the CCADB.

Created By: Kathleen Wilson (4/24/2018 4:59 PM)
The audit statement says:
"ETSI EN 319 411-1 NCP and the incorporated BRG-OVC standards as described in its Certificate Policies specified in Annex A."
and
"ETSI EN 319 411 v1.1.1 Part 1: NCP requirements. Where applicable, i.e. for issuance of certificates intended to be used for authenticating servers; services also comply with the PTC-BRG requirements for OVC."

NCP is a superset of LCP, so even though Mozilla's Policy[1] requires LCP+OVCP, NCP+OVCP is okay.

Our main concerns are:

1) Presumably BRG-OVC means OVCP, but we are uncomfortable with the ambiguity.

2) We are uncomfortable with the statement "Where applicable, i.e. for issuance of certificates intended to be used for
authenticating servers".
Mozilla's Policy states "For the SSL trust bit, a CA and all subordinate CAs *technically capable of issuing server certificates* must have one of the following audits..."
For a subordinate CA to not be "technically capable of issuing server certificates", it would have to be technically constrained via an EKU that does not contain id-kp-serverAuth or anyExtendedKeyUsage. [2]
Additionally, Mozilla's Policy requires that the audit statement also list the SHA-256 fingerprint for each intermediate certificate (i.e. subordinate CA certicate) that was in scope of the audit. [3]


[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#etsi

[2] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#technically-constrained

[3] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information

Comment 9

[Blake Morgan]

Hi Kathleen,

Apologies for the ambiguities in the audit statement.  We have reviewed the wording carefully and we propose the following adjustments to make it clearer.  The Auditors had re-used a previous statement which was satisfactory last year but we recognise it could be worded better.  Please have a look at this and advise if this is satisfactory re-wording before we issue a new statement.

Page 1.
Change to "......has implemented the requirements from ETSI EN 319 401 and ETSI EN 319 411-1 NCP & OVCP. See Appendix A for further details."

Appendix A.
Change to read only.... "The following facilities and services comprising the Trustis FPS PKI and certificate services are operated by Trustis in accordance with ETSI EN 319 401 and ETSI EN 319 411-1 NCP & OVCP." 

Trustis FPS Services Operate under the following PKI Certificate Authorities


Additionally SHA-2 Fingerprints will be provided.


Please let me know if this now meets your requirements.

Regards,
Blake

Comment 10

[Kathleen Wilson]

(In reply to Blake Morgan from comment #9)
> Hi Kathleen,
> 
> Apologies for the ambiguities in the audit statement.  We have reviewed the
> wording carefully and we propose the following adjustments to make it
> clearer.  The Auditors had re-used a previous statement which was
> satisfactory last year but we recognise it could be worded better.  Please
> have a look at this and advise if this is satisfactory re-wording before we
> issue a new statement.
> 
> Page 1.
> Change to "......has implemented the requirements from ETSI EN 319 401 and
> ETSI EN 319 411-1 NCP & OVCP. See Appendix A for further details."
> 
> Appendix A.
> Change to read only.... "The following facilities and services comprising
> the Trustis FPS PKI and certificate services are operated by Trustis in
> accordance with ETSI EN 319 401 and ETSI EN 319 411-1 NCP & OVCP." 
> 
> Trustis FPS Services Operate under the following PKI Certificate Authorities
> 
> 
> Additionally SHA-2 Fingerprints will be provided.
> 
> 
> Please let me know if this now meets your requirements.
> 
> Regards,
> Blake


Sounds good. Please proceed with this plan.

Comment 11

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_25_05_18_v6.2.pdf

Final version of the audit statement as agreed with Mozilla.

Comment 12

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_v1. Jan 19.pdf

Audit Statement for Trustis FPS Rooot CA for period of 17 Feb 2018 to 16 Jan 2019.

Comment 13

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_v1. Jan 19.pdf

This is the current ETSI EN 311 401 and EN 311 411-1 Audit Statement for the Trustis PFS Root

Comment 14

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_25_02_20.pdf

This is the new ETSI EN 319 401 and EN 319411-1 audit statement for the Trustis FPS Root CA

Comment 15

[Blake Morgan]

Comment on attachment 9129486 [details]
Entrust (Europe) Limited_ETSI_Verification_Statement_v1. Jan 19.pdf

Added in error, pleae ignore.

Comment 16

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_16_03_20_.pdf

This is the correct version of the Audit Statement as provided by LRQA.

Comment 17

[Blake Morgan]

Attachment: Entrust (Europe) Limited_ETSI_Verification_Statement_30_03_20..pdf

Following enquiries with the Audit body and root cause analysis regarding why there was confusion regarding Audit Coverage dates, this has now been resolved. Updated Audit Verification Certificate has been uploaded to this bug.
Incident report to follow in https://bugzilla.mozilla.org/show_bug.cgi?id=1623472

Comment 18

[Ryan Sleevi]

Kathleen: I wasn't sure, have you previously confirmed that LRQA is an appropriate auditor?

UKAS is the NAB for the UK, and while Lloyd's Register Quality Assurance is a CAB, I'm having trouble seeing how their accredited scope includes this, and/or how it meets the requirements set forth in ETSI EN 319 403.

LRQA is scoped against ISO/IEC 27001:2013 (ISMS) and ISO/IEC 20000-1:2011 and 2018 (ITSMS), but the ETSI standards are based on ISO 17065. Trustis is not using a qualified/notified scheme (which is only the GOV.uk eID scheme, AFAICT), so there's also that angle.

As it stands, based on the information provided by UKAS, I'm having trouble seeing how this auditor meets Section 8.2 of the Baseline Requirements:

(For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403;

Comment 19

[Ryan Sleevi]

Attachment: LRQA Certification Body qualifications from UKAS, accessed 2020-05-17

Comment 20

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #18)

Kathleen: I wasn't sure, have you previously confirmed that LRQA is an appropriate auditor?

Yes, but looking back through my email, I see that was in 2015, and I did not find evidence of re-checking this auditor's qualifications. I'll add that to my to-do list -- to recheck the qualifications of previously verified auditors.