Many thanks for reading and commenting on the policy documents. In
order to clarify and correct the issues which you highlight, new
versions (at version 1.3.2) of both CP and CPS have been published.
A summary of our actions follows. Paragraphs introduced with the text
"<TC>" indicate our response to the issues raised.
Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
TrustCor CA makes no authoritative statement, will have either the text “No
stipulation” or “Not Applicable”." but these sections are just blank."
<TC> The References and Conventions sections in both the CP and CPS
documents have had the blank space replaced with "No Stipulation".
"Level 2 Client certificates - demonstration of a pre-shared key and OTP
validation as described in Section 3.2.3 is sufficient to allow re- key."
however section 3.2.3 makes no mention of pre-shared key and OTP validation.
<TC>Section 3.2.3 has been updated to explicitly mention the multi
factor authentication steps as mentioned in 3.3.1.
"4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement."
<TC>This section of the CP has been replaced with one which
explicitly allows for publication to CT logs.
"OCSP responses may respond using the SHA-1 hash if the request used
SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
(section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
TrustCor does not, and never has, used SHA-1 as a component of any
signature algorithm on a certificate."
<TC>It is our reading of the BRs that the use of SHA-1 as a
_certificate_ signature is forbidden (including for OCSP Responder
certificates); not that such hashes are forbidden within the context
of OCSP Request/Response structure. Please note that our responder
_certificates_ do not use SHA-1, and never have. The text here only
mentions that signed OCSP responses (which have an maximum lifetime of
8 hours) may use SHA-1.
The text of this section has been revised to make completely clear
that the SHA-1 signature does NOT apply to responder certificates. It is
worth noting that section 4.3 of RFC 6960 states that OCSP clients SHOULD
be able to process such response signatures, indicating that such support
is to be reasonably expected.
Note that TrustCor is capable of removing SHA-1 as a signature hash on
OCSP responses, if the community determines it presents risk to the
relying parties. However, this does raise the risk to some clients
that would fail to understand the signature on the response. We
should prefer to service as many clients as faithfully as we can while
remaining true to the security principles of this community.
This section references version 1.3.0 of the BRs, which date from 2015."
<TC> This oversight has been corrected, and refers to the controlling
version of the BRs stipulated in the document overview section (1.1).
The maximum validity of the different certificate types, while within
what's allowed by the BRs, aren't consistent with the limits specified in
section 6.3.2 of the CP (e.g. 12 months vs 398 days)."
<TC>The CP has been corrected to refer to number of days, so as to be
consistent across all documents.
<TC> The CPS has been updated to use the correct URIs, namely:
Note that the Self-Assessment documents contained these (correct) URIs
- this was an oversight stemming from a DNS change which should have
been reflected in the CPS.
<TC>The URI now resolves to the correct (albeit unpopulated) incident
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers""
<TC>This has been corrected to include that word.
While it's good that TrustCor will publish cross-signed certificates it
issues to other CAs, my understanding of section 3.2.6 of the BRs is that
it requires cross certifications that a CA obtains from other CAs (i.e.
where it is the Subject of the cert) to be published."
<TC>Section 3.2.6 has been updated to make clear that bilateral publication
is honoured. That is, if a TrustCor certificate is cross-signed by another
CA, then TrustCor will make such publication known, in its normal certificate
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 188.8.131.52 does not list a subscriber request as a
reason for revocation."
<TC>The text has been clarified to include subscriber request as a valid
reason for revocation.
I would like to hope that there are technical, not just business, controls
in place to limit the actions an "insufficiently aware staff member" could
<TC>There are indeed technical controls, detailed in the security
policy (which forms part of the audit documentation) that restrict
actions of staff members. These include explicit ACLs, sudo
restrictions, mandatory access controls and so on, which all place
barriers to malicious or mistaken actions.
The text in the section has been amended to explicitly refer to those
Section 184.108.40.206 of the BRs states "certificatePolicies - This extension
MUST be present and SHOULD NOT be marked critical." for Subordinate CA
Certificates, however this section implies that certificatePolicies is only
specified for Enterprise Subordinate CAs."
<TC>The text has been updated to make clear that the certificatePolicies
applies to all Subordinate CA certificates, not just Enterprise Subordinate
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?"
<TC>The text has been changed to reflect that rfc822Name is the
subjectAlternativeName tag, and that the email address is its content.
It seems odd that this section references itself and 220.127.116.11. Where these
meant to be 18.104.22.168 and 22.214.171.124?"
<TC>The text has been updated. Indeed the references were supposed to
be 126.96.36.199 and 188.8.131.52 - those were dangling references to a different
document structure, now corrected.
"The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS."
<TC>This is an omission. The SKI and AKI have always been published. The
text is now updated in the CPS to be consistent with the language of
This seems at odds with 184.108.40.206 of the BRs.”
<TC>This was an omission. Policy identifiers are present in all
Subordinate CA certificates. This text was originally meant to refer
to Name Constraints and extendedKeyUsage identifiers, and not to
certificate policy identifiers (e.g. CPS OIDs and URIs). It has been
corrected to apply to all Subordinate CA certificates.