Re: root inclusion request

2017-10-12 Thread Andrew R. Whalley via dev-security-policy

I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:


CA diagrams are useful, thanks.


" may delegate the performance of *all or any* part of these
requirements to a Delegated Third Party" though the BRs preclude sections and - See ballot 215 which hopes to clear up any confusion
on this topic.

"may contractually authorize the Subject of a specified Valid EV
Certificate to perform the RA function and authorize to issue
additional EV Certificates at *third and higher domain levels* that are
contained within the domain of the original EV Certificate"

This assumes the number of labels in domains appearing in the Public Suffix
List, which is inadvisable.

1.5.5 CP/CPS annual review:  Might be worth making it explicit that there
will be a CP/CPS version number bump even if there is no change, per
Mozilla Root Store Policy v 2.5 §3.3

" shall confirm that, as of the date the Certificate issuance,
either *or a Delegated Third Party* has validated each
Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least
one of the methods listed below."

Section 1.3.2 of the BRs prohibits Delegated Third Parties from carrying
out procedures under § (even though it is allowed in this section of
the BRs) - See ballot 215 which hopes to clear up any confusion on this


" does not verify information contained in the Organization Unit
(OU) field in any certificate request"

Section of the BRs states: "The CA SHALL implement a process that
prevents an OU attribute from including a name, DBA, tradename, trademark,
address, location, or other text that refers to a specific natural person
or Legal Entity unless the CA has verified this information in accordance
with Section 3.2 and the Certificate also contains
subject:organizationName, , subject:givenName, subject:surname,
subject:localityName, and subject:countryName attributes, also verified in
accordance with Section"


"Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"

It's not immediately clear what non-subscribers are referred to in in §4.9.1

"f. nameConstraints (optional)

If present, this extension should not be marked critical*."

Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked

"It is forbidden for Intermediate CAs to issue end-entity Certificates
which blend the serverAuth (, emailProtection
( and codeSigning ( extended key



"Minor changes (e.g. correction of grammatical, syntactical, spelling
errors) may, at's sole discretion, be carried out without any prior
notice and without OID modification."

Even if the version number isn't changed, it would be good to ensure all
modifications, however minor, are listed in the Version Control table of




On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy <> wrote:

> On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> > This request from is to include the “ Root Certification
> Authority RSA”, “ Root Certification Authority ECC”, “ EV
> Root Certification Authority RSA”, and “ EV Root Certification
> Authority ECC” root certificates, turn on the Email and Websites trust bits
> for the two non-EV roots, turn on the Websites trust bit for the two EV
> roots, and enable EV treatment for the two EV roots.
> >
> > is a commercial organization that provides digital certificates
> in over 150 countries worldwide, with the goal of expanding adoption of
> encryption technologies and best practices through education, tools and
> expertise.
> >
> > The request is documented in the following bug:
> >
> >
> > BR Self Assessment is here:
> >
> >
> > Summary of Information Gathered and Verified:
> >
> >
> I will greatly appreciate it if someone will review and comment on this
> root inclusion request from
> Thanks,
> Kathleen
> ___
> dev-security-policy mailing list

Description: S/MIME Cryptographic Signature
dev-security-policy mailing list

Re: TrustCor root inclusion request

2017-08-17 Thread 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.



On Tue, Aug 15, 2017 at 12:18 PM, Neil Dunbar via dev-security-policy <> 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 <
>> 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:
> >
> >
> > 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 mailing list
dev-security-policy mailing list

Re: TrustCor root inclusion request

2017-08-10 Thread Andrew R. Whalley via dev-security-policy

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

*CP* (

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.

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

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

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

*CPS* (

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 is not resolving. is not resolving. is not resolving. is not resolving.

Commitment to make incident reports public - very good.
(Note that at the moment currently just
redirects to the home page)
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers"
Fail shut CAA - good

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.
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, does not list a subscriber request as a
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
Section 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.
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?
It seems odd that this section references itself and  Where these
meant to be and

The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS.
This seems at odds with 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,

dev-security-policy mailing list

Re: Symantec: Update

2017-05-10 Thread Andrew R. Whalley via dev-security-policy
On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy <> wrote:

> On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> > The next step, if Symantec wish to continue to use their current PKI in
> the future, should be logging (ASAP) *all* of the certificates they issued
> to a CT log, then we'll know how deep is the rabbit hole.
> already the case since '15
> digital-certificate-security.html

The blog post is dated October 15, but the requirement* only came into
effect June 1st, 2016

> although I'm not certain if this applied only to certs issued under the
> Symantec brand.

Any certs issued by any Symantec CA, regardless of brand, unless the CA is
operated by a 3rd party under its own, separate, audit.


*required for the cert to be trusted in Chrome.  They are still free to
issue certs that don't comply with the Chrome CT Policy, but those will
cause an interstitial warning in Chrome.

> dev-security-policy mailing list
dev-security-policy mailing list

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

2017-05-09 Thread Andrew R. Whalley via dev-security-policy

I've given the CP V1.6 and CPS V4.5 docs a quick looking through and have
the following comments:

* Please don't protect your PDFs for printing

* - which I believe should be revoked, has
also expired.  The revoked test cert should be otherwise valid and not

* While there is mention of how CAA records are dealt with in section
4.2.4, it doesn't seem to specify what value is expected to be present in
the record for the check to pass.

* 3.2.7. 域名的确认和鉴别 Domain name recognition and identification - This section
references BR version v1.4.1. Version 1.4.4 is current and has changes in
the section numbers referred to here.  (Also see versions under IPR review
on the CAB Forum website)

* 7.1 Certificate profile: There is no mention of how the serial number is
generated. The BRs specify "Effective September 30, 2016, CAs SHALL
generate non‐sequential Certificate serial numbers greater than zero (0)
containing at least 64 bits of output from a CSPRNG."

* CP 7.1.3 says "The cryptographic algorithm identifiers of certificates
issued by GDCA include sha1RSA, sha256RSA and sha256ECDSA".  SHA1
signatures must not be used in any part of the publically trusted hierarchy.

* CP 7.1.5 on "Name Constraints" looks like it's referring to 3.1.2 "Need
for names to be meaningful".  This section is meant to refer to RFC 5280
section name constraints.

* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in - it would be great to get them
CT logged.

* Only GDCA TrustAUTH R5 ROOT (SHA-1 Fingerprint
0F:36:38:5B:81:1A:25:C3:9B:31:4E:83:CA:E9:34:66:70:CC:74:B4) seems to have
been disclosed in Mozilla's CCADB.



On Sat, Apr 22, 2017 at 5:08 AM, wangsn1206--- via dev-security-policy <> wrote:

> 在 2017年4月20日星期四 UTC+8下午11:31:14,Patrick Tronnier写道:
> > On Thursday, April 20, 2017 at 9:30:31 AM UTC-4,
> wrote:
> > > We have just published the updated CP/CPS documents, this version has
> been revised according to the latest Baseline Requirements and has been
> reviewed internally, meanwhile, the points our “Analysis on the Compliance
> of GDCA’s CP and CPS with the Baseline Requirements (published on March 25,
> 2017)” promised to disclose have been included in this version, and we will
> update the compliance analysis document as soon as possible. Please find
> the new version at:
> > > CP V1.6:
> cgi?id=8860016
> > > CPS V4.5:
> cgi?id=8860018
> > > EV CP V1.4:
> cgi?id=8860019
> > > EV CPS V1.5:
> cgi?id=8860020
> > >
> > > We wish these documents will be fully discussed by the public, so that
> Mozilla can make decision on this root inclusion application.
> > > All comments and suggestions are welcomed. Thanks.
> >
> > I updated your bug with a review of your initial BR-self-assessment
> using the previously posted CPS's. The review is attachment
> >
> > Would you please complete a second BR-self-assessment against the just
> posted CPS's and CP's and use my attachment as your starting point? Thank
> you.
> Hi Patrick,
> Thanks for the comments.
> Please check our second BR self-assessment against our updated CP/CPS (CP
> V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5).You can find the document at
> the following address of the BUG:https://bugzilla.mozilla.
> org/attachment.cgi?id=8860627
> We welcome all comments and suggestions.
> Thanks.
> ___
> dev-security-policy mailing list
dev-security-policy mailing list

Re: Include Renewed Kamu SM root certificate

2017-03-03 Thread Andrew R. Whalley via dev-security-policy

I've read though the English language version of CP/CPS dated March 30,
2016 version 1 and made the following notes:

No version history at the front of the document.  This not required, but is
evidence of good document change management and is a useful reference to
see what's changed when coming back to reviewing docs.

1.2 Document Name and Identification

Document version number is 3, but the front page and headers say version
1.  Please clarify.

3.1.5 Uniqueness of Names

CN Field: Note that use of the common name is deprecated.

3.2.2 Authentication of Organization Identity

This section states "WHOIS records pertinent to domain name specified in
the certificate application shall be verified via ''". It would
be useful to have more detail on the validation method. See section
of the Baseline Requirements.

4.9.3 Procedure for Revocation Request

The Baseline Requirements for this section state: "The CA SHALL provide
Subscribers, Relying Parties, Application Software Suppliers, and other
third parties with clear instructions for reporting suspected Private Key
Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to Certificates.
The CA SHALL publicly disclose the instructions through a readily
accessible online means."

As such instructions aren't included in the CP/CPS, could you point to
where they can be found?

6.5.1 Specific Computer Security Technical Requirements

Please make sure use of anti virus is properly risk managed. There have
been a worrying number of high severity bugs in popular anti virus
software, including privileged remote code execution.

7.2.2 CRL and CRL Entry Extensions

Though optional, CRL reason codes are encouraged.

9.4.3 Information Not Deemed Private

The contents of publicly trusted certificates should always be treated as
public even if such a an agreement or contract is in place.

10.3 End Entity SSL Certificate Template

For Serial Number, a unique number is insufficient, per BRs "CAs SHALL
generate non‐sequential Certificate serial numbers greater than zero (0)
containing at least 64 bits of output from a CSPRNG."


Overall the document was clear and well written and didn't contain anything
too worrying.



On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilson 

> This request from the Government of Turkey, Kamu Sertifikasyon Merkezi
> (Kamu SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum
> 1” root certificate, and enable the Websites trust bit. This SHA-256 root
> certificate will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika
> Hizmet Sağlayıcısı - Sürüm 3” root certificate that was included via
> Bugzilla Bug #381974. The old root certificate expires in August, 2017.
> Note that the CA has indicated that since Kamu SM is a government CA , the
> CA only issues certificates to government-owned domains (restricted by
> these TLDs:,,,,,,,
> and ) and does not issue any certificates outside of Turkey. So,
> Mozilla may constrain this root to those domains.
> The request is documented in the following bug:
> And in the pending certificates list:
> Summary of Information Gathered and Verified:
> * Root Certificate Download URL:
> * The primary document, the SSL CP/CPS, is provided in both Turkish and
> English.
> Document Repository:
> * CA Hierarchy: This root certificate has internally operated subordinate
> CAs that issue SSL end-entity certificates.
> * This request is to turn on the Websites trust bit.
> ** SSL CP/CPS section 3.2.2: Authentication of government agencies having
> requested OV SSL certificate from Kamu SM shall be performed by way of
> verification from official correspondences made between Kamu SM, relevant
> government agency and relevant channels of domain ownership (e.g.,
> ).
> All applications made to Kamu SM shall be supported with legal documents
> that shall authenticate the following information and some of this
> information shall be included within the Subject field:
> …...
> Residence address of applicant government agency is taken as a basis in OV
> SSL applications. Legal status, identification information, domain name,
> organization representative, presence of application, CSR information and
> other similar information of applicant should be verified. Since the
> organization authentication is of high importance while issuing OV SSL