Re: SSL.com root inclusion request
Greetings, I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes: 1.3. CA diagrams are useful, thanks. 1.3.2 "SSL.com may delegate the performance of *all or any* part of these requirements to a Delegated Third Party" though the BRs preclude sections 3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion on this topic. 1.3.2.1 "may contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize SSL.com 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 SSL.com 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 3.2.2.4 "SSL.com shall confirm that, as of the date the Certificate issuance, either SSL.com *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 §3.2.2.4 (even though it is allowed in this section of the BRs) - See ballot 215 which hopes to clear up any confusion on this topic. 3.2.4 "SSL.com does not verify information contained in the Organization Unit (OU) field in any certificate request" Section 7.1.4.2.1 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 3.2.2.1." 4.9.2 "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 7.1.2.2 "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 critical." "It is forbidden for Intermediate CAs to issue end-entity Certificates which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection (1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key usages." Good 9.12.1/2 "Minor changes (e.g. correction of grammatical, syntactical, spelling errors) may, at SSL.com'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 §1.2.1 -- Cheers, Andrew On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote: > > This request from SSL.com is to include the “SSL.com Root Certification > Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV > Root Certification Authority RSA”, and “SSL.com 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. > > > > SSL.com 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: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1277336 > > > > BR Self Assessment is here: > > https://bugzilla.mozilla.org/attachment.cgi?id=8881939 > > > > Summary of Information Gathered and Verified: > > https://bugzilla.mozilla.org/attachment.cgi?id=8895068 > > > > > I will greatly appreciate it if someone will review and comment on this > root inclusion request from SSL.com. > > Thanks, > Kathleen > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TrustCor root inclusion request
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
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: Symantec: Update
On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy < dev-security-policy@lists.mozilla.org> 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 > > https://security.googleblog.com/2015/10/sustaining- > 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. Andrew *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@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: Guang Dong Certificate Authority (GDCA) root inclusion request
Greetings, 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 * https://SSLTEST-2.95105813.cn - which I believe should be revoked, has also expired. The revoked test cert should be otherwise valid and not expired. * 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 4.2.1.10 name constraints. * CPS Appendix1: Certificate information of the publicly trusted CAs: Most of the listed CAs can't be found in crt.sh - 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. Thanks, Andrew On Sat, Apr 22, 2017 at 5:08 AM, wangsn1206--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 在 2017年4月20日星期四 UTC+8下午11:31:14，Patrick Tronnier写道： > > On Thursday, April 20, 2017 at 9:30:31 AM UTC-4, wangs...@gmail.com > 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: https://bug1128392.bmoattachments.org/attachment. > cgi?id=8860016 > > > CPS V4.5: https://bug1128392.bmoattachments.org/attachment. > cgi?id=8860018 > > > EV CP V1.4: https://bug1128392.bmoattachments.org/attachment. > cgi?id=8860019 > > > EV CPS V1.5: https://bug1128392.bmoattachments.org/attachment. > 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 > https://bugzilla.mozilla.org/attachment.cgi?id=8860075. > > > > 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@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: Include Renewed Kamu SM root certificate
Hello, 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 'www.nic.tr'". It would be useful to have more detail on the validation method. See section 3.2.2.4 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. Cheers, Andrew On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilson wrote: > 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: gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr > and org.tr ) 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: > https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967 > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=8738995 > http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer > > * The primary document, the SSL CP/CPS, is provided in both Turkish and > English. > > Document Repository: http://depo.kamusm.gov.tr/ilke/ > SSL CP/CPS: > http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf > http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf > > * 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., nic.tr > ). > 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 > certificate, all information to b
