Re: TrustCor root inclusion request

[Kathleen Wilson via dev-security-policy]

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



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Kathleen Wilson via dev-security-policy]

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
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Andrew R. Whalley via dev-security-policy]

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-security-policy@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-security-policy@lists.mozilla.org> wrote:
> >
> > On Mon, 14 Aug 2017 20:27:05 +0100
> > Neil Dunbar via dev-security-policy
> >  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.
> 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
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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 
>  wrote:
> 
> On Mon, 14 Aug 2017 20:27:05 +0100
> Neil Dunbar via dev-security-policy
>  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.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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Jakob Bohm via dev-security-policy]

On 14/08/2017 21:48, Andrew Ayer wrote:

On Mon, 14 Aug 2017 20:27:05 +0100
Neil Dunbar via dev-security-policy
 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.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



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 0x0080 
    ).

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Andrew Ayer via dev-security-policy]

On Mon, 14 Aug 2017 20:27:05 +0100
Neil Dunbar via dev-security-policy
 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.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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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

 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.

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

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

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

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

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

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

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

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

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 

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

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

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Andrew R. Whalley via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 18/05/17 23:40, Nick Lamb wrote:
>> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
>> here? Judging from self-assessment document, TrustCor's actual
>> practices are all intended to be 3.2.2.4 compliant (I will examine in
>> more detail later) but the language here suggests it might be
>> possible for applicants to successfully validate for DV by some other
>> means not listed in 3.2.2.4, which (again unless I'm mistaken)
>> Mozilla considers always to be mis-issuance.
> 
> As of 21st July 2017, yes :-) The language should be clear that only
> 3.2.2.4-conforming methods are allowed, and each documented method
> should say which subsection of 3.2.2.4 it is complying with.

The BR self assessment document (as well as the CPS) does indeed stipulate 
which of the 3.2.2.4 subsections are allowed in validation of a DV certificate. 
No methods outside of 3.2.2.4 are permitted. The WHOIS method mentioned here is 
allowed via BR 3.2.2.4.1. Note that not all of the allowed methods from the 
3.2.2.4 subsections are actually used by TrustCor. It is possible that the 
self-assessment summary might lead to the (incorrect) conclusion that methods 
other than 3.2.2.4 could be successful, but the TrustCor documents make clear 
that only 3.2.2.4 methods are allowed

With respect to the particular clause referring to WHOIS, from the current CPS:

"3.2.2.4.1 Validating the Applicant as a Domain Contact
TrustCor will use the WHOIS or RDAP protocols to gain the Domain
Registration document for the domain(s) being requested for certification.
The email address, name, physical address present in the WHOIS record
must match those details submitted as part of the application."

Regards,

Neil Dunbar
CA Administrator,
TrustCor Systems, S. de R.L.



signature.asc
Description: Message signed with OpenPGP
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Gervase Markham via dev-security-policy]

On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it might be
> possible for applicants to successfully validate for DV by some other
> means not listed in 3.2.2.4, which (again unless I'm mistaken)
> Mozilla considers always to be mis-issuance.

As of 21st July 2017, yes :-) The language should be clear that only
3.2.2.4-conforming methods are allowed, and each documented method
should say which subsection of 3.2.2.4 it is complying with.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Nick Lamb via dev-security-policy]

On Thursday, 18 May 2017 04:23:17 UTC+1, Aaron Wu  wrote:
> - DV SSL Certificates - the domain name registrar must list the applicant as 
> part of the WHOIS record; or effective control of the domain shall be 
> demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be 
> obtained. 

Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong here? Judging 
from self-assessment document, TrustCor's actual practices are all intended to 
be 3.2.2.4 compliant (I will examine in more detail later) but the language 
here suggests it might be possible for applicants to successfully validate for 
DV by some other means not listed in 3.2.2.4, which (again unless I'm mistaken) 
Mozilla considers always to be mis-issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

TrustCor root inclusion request

[Aaron Wu via dev-security-policy]

This request from TrustCor is 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.

TrustCor, located in Canada, is a commercial organization that develops privacy 
protection services and issues certificates to its customers in support of such 
services.

The request is documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1231853

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8860163

Summary of Information Gathered and Verified: 
https://bugzilla.mozilla.org/attachment.cgi?id=8868831

* Root Certificate Download URL: 
http://www.trustcor.ca/certs/root/ca1.pem
http://www.trustcor.ca/certs/root/ca2.pem
http://www.trustcor.ca/certs/root/eca1.pem

* All documents are in English.
Document Repository: https://www.trustcorsystems.com/resources/
CP:  http://www.trustcor.ca/resources/cp.pdf 
CPS:  http://www.trustcor.ca/resources/cps.pdf 

* CA Hierarchy: 
The “TrustCor RootCert CA-1” and “TrustCor RootCert CA-2” root certificates 
issue internally-operated intermediate certificates that sign SSL and S/MIME 
certificates. These root certs will not have any externally-operated subCAs.
The Enterprise Root Certificate, “TrustCor ECA-1”,  is the only root allowed to 
issue externally-operated subCAs.

* This request is to turn on the Websites and Email trust bit. EV treatment is 
not requested.

** CP 3.2.5 Validation of authority
TrustCor CA, or any authorized external RA, must verify the evidence 
accompanying a certificate request according to the following certificate 
types: 
- DV SSL Certificates - the domain name registrar must list the applicant as 
part of the WHOIS record; or effective control of the domain shall be 
demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be 
obtained. 
- OV SSL Certificates - In addition to the communications as per DV SSL 
Certificates, the CA/RA must also be satisfied that such assurances as per BR 
3.2.2.2 and BR 3.2.2.3 have been completed. Specifically, reliable data sources 
such as government registries of incorporation shall be consulted to verify 
that the organizational identity can be reasonably asserted in the certificate 
subject. 
- S/MIME Certificates - the requestor must demonstrate control over receiving 
and sending messages from the specified email address.
- Level 2 Individual-Organizational Certificates - the CA must possess 
communication delivered using a reliable method that the individual has an 
ongoing association with the organization; and that this communication must be 
sourced from someone in the organization 29 with the ability to speak 
authoritatively for its associations (e.g. an HR representative, the signatory 
to a contract of employment, etc.)

* EV Policy OID: Not Requesting EV treatment 

* Test Websites
RootCert CA-1 valid: https://catest1.trustcor.ca/ 
RootCert CA-1 revoked: https://catest1-revoked.trustcor.ca/ 
RootCert CA-1 expired: https://catest1-expired.trustcor.ca/ 

RootCert CA-2 valid: https://catest2.trustcor.ca/ 
RootCert CA-2 revoked: https://catest2-revoked.trustcor.ca/ 
RootCert CA-2 expired: https://catest2-expired.trustcor.ca/ 

ECA1-External valid: https://valid.epki.external.trustcor.ca/ 
ECA1-External revoked: https://revoked.epki.external.trustcor.ca/ 
ECA1-External expired: https://expired.epki.external.trustcor.ca/

* CRL URLs: 
CA1 -  http://crl.trustcor.ca/root/ca1.crl 
CA1 - http://crl.trustcor.ca/root/ca2.crl 
ECA1 - http://crl.trustcor.ca/root/eca1.crl 

* OCSP URLs:
CA1 - http://ocsp.trustcor.ca/root/ca1
CA2 - http://ocsp.trustcor.ca/root/ca2
ECA1 - http://ocsp.trustcor.ca/root/eca1
Maximum expiration time of OCSP responses: 4 days

* Audit: Annual audits are performed by Princeton Audit Group (PAG) according 
to the WebTrust for CA and BR audit criteria.
https://cert.webtrust.org/SealFile?seal=2169=pdf
https://cert.webtrust.org/SealFile?seal=2163=pdf 

* Forbidden or Problematic Practices 
(https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices)
** Delegation of Domain / Email Validation to Third Parties
** Allowing External Entities to Operate Subordinate CAs
*** CPS section 1.3.1: The Enterprise Root Certificate (ECA-1) - used as the 
ultimate root for enterprise PKIs issuing credentials to their principals in 
restricted namespaces. ...
TrustCor CA undertakes to ensure that all operations conducted using these 
certificates, including registration of entities, validation of same, issuance 
and revocation of certificates are performed in accordance with the strictures 
of this document, the governing CP. Note that Enterprise Subordinate CA 
certificates are still TrustCor CA certificates, and TrustCor CA is responsible 
for their issuance, insofar as the enterprise subscriber agreements is obeyed. 
TrustCor CA is responsible for revoking an enterprise subordinate CA should it 
discover substantive violations of its