Re: TrustCor root inclusion request

[Andrew R. Whalley]

Greetings,

I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
following notes:

*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
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.

3.3.1
"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.

4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement.

6.1.5
"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.

6.1.6
This section references version 1.3.0 of the BRs, which date from 2015.

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

1.4.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).

2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving.

2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)

3.2.2.4.7
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers"

3.2.2.8
Fail shut CAA - good

3.2.6
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.

4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 4.9.1.1 does not list a subscriber request as a
reason for revocation.

4.9.1.2
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
perform.

7.1.2.2
Section 7.1.2.2 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.

7.1.2.3
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?

7.1.2.4
It seems odd that this section references itself and 7.1.2.5. Where these
meant to be 7.1.2.2 and 7.1.2.3?

The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS.

7.1.6.3
This seems at odds with 7.1.2.2 of the BRs.

Those comments aside, I found both documents clear, well written, and they
provided sufficient detail to assess the policies in place.

Many thanks,

Andrew

[Neil Dunbar]

Andrew.

Thank you for the review, comments and questions on TrustCor's policy documents.

We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Neil Dunbar]

[Neil Dunbar]

[Neil Dunbar]

Andrew,

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.

"*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
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".

3.3.1
"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.

"6.1.5
"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.

"6.1.6
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).

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

"1.4.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.

"2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving."

<TC> The CPS has been updated to use the correct URIs, namely:

https://catest1-revoke.trustcor.ca/
https://catest1-expire.trustcor.ca/
https://catest2-revoke.trustcor.ca/
https://catest2-expire.trustcor.ca/

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.

"2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)"

<TC>The URI now resolves to the correct (albeit unpopulated) incident
page.

"3.2.2.4.7
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.

"3.2.6
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
repository.

"4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 4.9.1.1 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.

"4.9.1.2
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
perform."

<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
controls.

"7.1.2.2
Section 7.1.2.2 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

CAs.

"7.1.2.3
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.

"7.1.2.4
It seems odd that this section references itself and 7.1.2.5. Where these
meant to be 7.1.2.2 and 7.1.2.3?"

<TC>The text has been updated. Indeed the references were supposed to
be 7.1.2.2 and 7.1.2.3 - 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
the CP.

"7.1.6.3
This seems at odds with 7.1.2.2 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.

Best regards,

Neil Dunbar

[Andrew Ayer]

On Mon, 14 Aug 2017 20:27:05 +0100
Neil Dunbar via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> 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.

Yes, OCSP responses signed with SHA-1 do present a risk, since a
chosen prefix attack can be performed to forge OCSP responses and even
certificates:
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html

Even if you technically constrain your OCSP responder certificates as
required by Mozilla policy section 5.1.1, forged OCSP responses are
still possible if you use SHA-1. That would allow attackers to use
revoked certificates. So it would be better if you didn't use SHA-1 at
all for OCSP responses.

Thanks for your consideration of security feedback from the community.

Regards,
Andrew

[Jakob Bohm]

As this issue has come up before, I would like to ask the following
general question:

Would the following technical solution be acceptable for CAs that issued
SHA-1 certificates in the past (before 2016):

1. All recent non-SHA-1 certificates trace primarily to a root CA that
never, directly or indirectly, issued valid SHA-1 certificates (e.g a
"Whatever CA root R2"), but may be cross-signed by the old root(s).

2. All recent non-SHA-1 certificates contain revocation URLs different
from those used in SHA-1 certificates.

3. OCSP queries that contain client-specified nonces, multiple
certificates etc. no longer get responses signed with SHA-1. I
believe that implementations that only accept SHA-1 signed responses
rarely make such requests (please inform the list if this is not the
case).

4. Other OCSP queries for actually issued SHA-1 certificates (revoked or
not) chaining to the old root get responses that are SHA-1 signed by
dedicated SHA-1 OCSP certificates issued from the old roots. Such
responses contain the following randomized elements chosen by the OCSP
responder and/or OCSP response pre-signing process. The randomized
elements shall provide at least 256 bits of random entropy as close to
the start of the signed response as the standards and interoperability
allow: The "producedAt" timestamp shall be randomized over a 24 hour
period before intended response validity start, at 1attosecond
(fake) resolution (this provides 76 bits of entropy). The
"thisUpdate" field in the only SingleResponse shall be randomized in
the same way (this provides an additional 76 bits of entropy). The
"nextUpdate" field shall be present and shall be randomized into the
future in the same way (an additional 76 bits), finally there shall be
a non-critical singleExtension of an appropriate OID (not the OCSP
nonce OID) that sorts before all other extensions used, and whose
value is an OCTET STRING containing enough random octets to make up
the balance of the 256 bit minimum.

5. Such OCSP processes continue to run (with increasingly strong
countermeasures) until there is no more reason to check the validity
of any actually issued SHA-1 certificates (this would be the expiry of
the last such certificate for TLS server/client certs, but much later
for e-mail, document and other certs that are likely to be checked
for historical validity after their expiry), compare to the discussion
of archival cutoff in RFC2560.

6. Similarly, CRLs covering such historic SHA-1 certificates may be
signed with SHA-1 provided they contain strong randomized elements
chosen by the CA (such as pseudo-revocation of random never-issued
certificate serial numbers that sort at the start of the generated
CRL, for example 9 serial numbers of the form 0x00800000 00000000
00000000 00000000 rrrrrrrr).

7. Similar distinctions are established between the hierarchies that
chain to different current signature algorithms, to minimize risks
associated with future distrust of such algorithms.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Neil Dunbar]

Andrew,

SHA-1 has been removed from the TrustCor OCSP list of acceptable hash algorithms for responder signatures.

The minimum hash deemed acceptable now is SHA-256. We have updated the CP/CPS in section 6.1.5 to clarify that SHA-1 will no longer be honoured as a signature algorithm.

Best regards,

Neil Dunbar
TrustCor CA Administrator

> On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Mon, 14 Aug 2017 20:27:05 +0100
> Neil Dunbar via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> 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.
>
> Yes, OCSP responses signed with SHA-1 do present a risk, since a
> chosen prefix attack can be performed to forge OCSP responses and even
> certificates:
> https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html
>
> Even if you technically constrain your OCSP responder certificates as
> required by Mozilla policy section 5.1.1, forged OCSP responses are
> still possible if you use SHA-1. That would allow attackers to use
> revoked certificates. So it would be better if you didn't use SHA-1 at
> all for OCSP responses.
>
> Thanks for your consideration of security feedback from the community.
>
> Regards,
> Andrew

[Andrew R. Whalley]

Thanks Neil,

I've looked over the updated CP and CPS documents and have no further
comments or questions.

Cheers,

Andrew

On Tue, Aug 15, 2017 at 12:18 PM, Neil Dunbar via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> Andrew,
>
> SHA-1 has been removed from the TrustCor OCSP list of acceptable hash
> algorithms for responder signatures.
>
> The minimum hash deemed acceptable now is SHA-256. We have updated the
> CP/CPS in section 6.1.5 to clarify that SHA-1 will no longer be honoured as
> a signature algorithm.
>
> Best regards,
>
> Neil Dunbar
> TrustCor CA Administrator
>
>
> > On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > On Mon, 14 Aug 2017 20:27:05 +0100
> > Neil Dunbar via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >
> >> 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.
> >
> > Yes, OCSP responses signed with SHA-1 do present a risk, since a
> > chosen prefix attack can be performed to forge OCSP responses and even
> > certificates:

> > https://www.mail-archive.com/dev-security-policy@lists.

[Kathleen Wilson]

Thank you to everyone who has reviewed and commented on this request from TrustCor to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits.

I believe that all of the questions and concerns have been addressed and resolved.

Therefore, if no further concerns are raised, I intend to close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

Thanks again to everyone reviewed and commented on this request from TrustCor.

I am now closing this discussion, and will recommend approval in the bug to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits.


https://bugzilla.mozilla.org/show_bug.cgi?id=1231853

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen