RE: Violations of Baseline Requirements 4.9.10
Hi Ben, DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Downloading the issuer (https://crt.sh/?id=8949008) and then running: openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.root.cartaodecidadao.pt/publico/ocsp -noverify gives this response: 101010101010101101010101010: good This Update: Nov 14 23:59:47 2017 GMT So this does not appear to be resolved. DN: C=PT, O=SCEE, CN=ECRaizEstado The SCEE root for the Government of Portugal is now responding with unknown/revoked statuses. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Download https://crt.sh/?id=8642581 and run: openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/ocsp -noverify and openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010 -no_nonce -url http://ocsp.multicert.com/procsp -noverify and the responses are: 101010101010101101010101010: good This Update: Nov 15 00:03:40 2017 GMT Next Update: Nov 15 00:03:40 2017 GMT 101010101010101101010101010: good This Update: Nov 15 00:03:58 2017 GMT Next Update: Nov 15 00:03:58 2017 GMT Not fixed. DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 (Issuer: https://crt.sh/?id=128496365) openssl ocsp -issuer 128496365.crt -serial 1010101010101010101002101010 -no_nonce -noverify -url http://ocsp.multicert.com/ocsp 1010101010101010101002101010: good This Update: Nov 15 00:15:45 2017 GMT Next Update: Nov 15 00:15:45 2017 GMT Also not fixed. I believe Kathleen has opened bugzilla issues for these so it would probably be good to copy this correspondence there as well. -Paul On November 15, 2017 at 6:50:43 AM, Ben Wilson (ben.wil...@digicert.com) wrote: Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Example cert: https://crt.sh/?id=117934576 OCSP URI: http://ocsp.multicert.com/ocsp OCSP URI: http://ocsp.multicert.com/procsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 Example cert: https://crt.sh/?id=11653177 OCSP URI: http://ocsp.multicert.com/ocsp DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State: DN: C=PT, O=SCEE, CN=ECRaizEstado Example cert: https://crt.sh/?id=8322256 OCSP URI: http://ocsp.ecee.gov.pt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Violations of Baseline Requirements 4.9.10
Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002 Example cert: https://crt.sh/?id=117934576 OCSP URI: http://ocsp.multicert.com/ocsp OCSP URI: http://ocsp.multicert.com/procsp DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001 Example cert: https://crt.sh/?id=11653177 OCSP URI: http://ocsp.multicert.com/ocsp DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State: DN: C=PT, O=SCEE, CN=ECRaizEstado Example cert: https://crt.sh/?id=8322256 OCSP URI: http://ocsp.ecee.gov.pt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Forbidden Practices: Subscriber key generation
Hi Gerv and Kathleen, We're working on the Mozilla CA self-assessment checklist and referenced requirements you have placed on CAs. On your page of Forbidden or Problematic Practices [1], you state that CAs must not generate private keys for signer certificates. CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME encryption certificates. The Code signing standard [2], section 10.2.4 permits CAs to generate private keys for code signing certificates. Specifically: If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service's secure infrastructure, then the entity generating the Private Key MUST either transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption or encrypt the Private Key with at least 128 bits of encryption strength. Allowed methods include using a 128-bit AES key to wrap the private key or storing the key in a PKCS 12 file encrypted with a randomly generated password of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols for transport. The question is, if we issue Code Signing certificates via P12 files in compliance with the Code Signing standard, are we out of compliance with the Mozilla policy? How do you recommend we respond to this checklist question? And the same for S/MIME and SSL certificates. If CAs generate and then securely distribute the keys to the subscribers using similar methods, is that permitted provided we implement similar security, or does that practice need to immediately stop? Your guidance in this area would be appreciated. Side question: Is there a deadline when you expect to receive self-assessments from all CAs? We've found that complying with the checklist means a major update to our CPS (among other things...), and I suspect most other CAs will also need a major update. Doug [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices [2] https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf Doug Beattie Product Mangement GMO GlobalSign, Inc. Portsmouth, NH USA ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On Tuesday, November 14, 2017 at 8:31:34 AM UTC-8, Kathleen Wilson wrote: > On 11/14/17 4:34 AM, douglas...@gmail.com wrote: > > > > Do we believe that this issue has been resolved by the Registry and > > issuance an resume as normal, or are there ongoing concerns which CAs > > should be aware of when issuing certificates to .tg domains? > > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. Let's Encrypt disabled issuance to .tg on November 1 as a protective measure. The block remains in place. We'd like to lift the block but we have seen no evidence that the problem was ever acknowledged or fixed by anyone involved in running the .tg registry. Most of the issuance to .tg during the problematic period was from Let's Encrypt (note that validation was successfully completed, Let's Encrypt did not mis-issue). Since we disabled issuance to .tg on Nov 1 a lack of new suspicious issuance may only reflect our block, not resolution of problems. The fact that some large companies got control of their domains back may only reflect customer service actions. We are stuck in a difficult situation where we'd like to re-enable issuance to .tg but we just don't have confidence that the registry is secure. If anyone has any direct evidence we'd greatly appreciate seeing it. Without more evidence we will simply have to re-enable .tg issuance and monitor it for a period of time. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Swiss Government root inclusion request
Hello Wayne, At me the link on the pdf file is work correctly from Google Chrome ver. 49, but I cannot load this file in my post... ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Swiss Government root inclusion request
I reviewed the CP/CPS, BR self assessment, audit statement, and other information provided as part of this request. Overall, I found the CPS and BR self assessment to be lacking in detail, and in some cases the CPS references non-public documents. Here are my specific comments: - I’m also receiving a 404 periodically when loading http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf, leading me to believe that the file is missing from one or more servers. - The audit statement linked above doesn’t include the period covered nor list any of the sub-CAs covered as required by Mozilla policy section 3.1.4. - The current 1.4 version of the CPS at https://www.bit.admin.ch/adminpki/00243/06257/index.html?lang=de dated 2017-08-17 uses obsolete descriptions of domain authorization methods in section 3.2.2.4. These methods are not described at the level of detail required by Mozilla policy and may not comply with the current version of the BRs. - The answer to the self-assessment question 1.3.2 on Delegated Third Parties states that “CA does not allow initial identity validation delegated to third parties”; however, CPS section 1.3.2 uses the [undefined] term 'Registration Agent' to describe what appears may be a Delegated Third Party in 1.3.2.3. - BR 4.9.3 requires the CA to publicly disclose instructions for problem reporting through a readily accessible online means. Section 4.10.2 of the CPS states that ‘High-Priority Certificate Problem Reports can be submitted on the SG PKI Homepage 24x7’ but I don’t find any clear reference to problem reporting at https://www.bit.admin.ch/adminpki/. - The current 1.4 version of the CPS at https://www.bit.admin.ch/adminpki/00243/06257/index.html?lang=de dated 2017-08-17 does not include information about CAA as required by the latest version of the BRs. - The CP/CPS doesn’t include the conformance statement required by BR section 2.2. - The CP/CPS doesn’t specify how it is licensed per Mozilla policy 3.3(3). - Section 4.1.1 of the CPS describes the enrollment process but does not mention how suspicious certificate requests are identified. - Section 4.2.1 of the CPS does not provide any information on high risk certificate requests. - Section 4.2.2 makes 'Domain names within the range assigned to the requesting Registration Agent (as of 3.2.3)' a 'Condition for Approval', but section 3.2.3 is titled ‘Authentication of individual identity’ and doesn’t appear to describe domain restrictions. - Section 7.1.2.3 refers the reader to the 'Object Identifiers' document at https://www.bit.admin.ch/adminpki/00243/index.html?lang=de for subscriber certificate profiles. I believe the reference should be to the 'CA Layout and Policies' document at the same location. Please note that responses to section 3 of the BR self-assessment included references to a “Checklist”, but I’m unable to load http://www.pki.admin.ch/public/83823_Checkliste-Genehm-SSL-TLS-ZertifAntr-CAs-SwissGov-PKI-160513-e_pub.pdf (I get a 404), so my comments do not reflect any information contained therein. Thanks, Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote: Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? Based on information from folks that are monitoring their NS Records, we believe that the .tg Registry problems were fixed on November 1, and have remained fixed since then. I have not looked into how Registries are operated and maintained, so here is my personal (uneducated) opinion: I think it is possible that the .tg Registry could be compromised again. I have no idea if all of the newer Registries are using good network and security protocols, infrastructure, etc. I think that we will need to have much deeper investigation and discussions about Registries, so I have added this to my to-do list, but I will not be able to get to it until January. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On 11/13/17 7:22 PM, Jakob Bohm wrote: Wouldn't the .tg incident be equally relevant for the e-mail trust bit? (In which case the first 3 options should say TLS/SSL/e-mail) Good point. To make it easier, I removed "TLS/SSL", and changed text to "certificates containing .tg domains". Updated as follows: ~~ ACTION 8: Check for issuance of certificates containing .tg domains from October 25 to November 2, 2017. We believe that the .tg Registry was compromised from October 25 to November 1, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained certificates for those domains. Please check the certificates containing .tg domains that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. Response Options: - There are no certificates containing .tg domains that chain up to our root certificates included in Mozilla's program. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, but there were no new validations on .tg domains from October 25 to November 2, 2017. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, and we have re-verified the certificates that were issued for .tg domains from October 25 to November 2, 2017, and no problems were found. - We have revoked certificates containing .tg domains that were issued between October 25 and November 2, 2017, and have sent information about these revoked certificates to Mozilla. - Other - explain ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On Monday, November 6, 2017 at 6:40:58 AM UTC-5, Ben Laurie wrote: > On 4 November 2017 at 19:54, Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 11/4/17 5:36 AM, Daniel Cater wrote: > > > > I think those CAs need to re-validate their recently issued SSL certs that > > contain any *.tg domains, and possibly revoke such certs and send us the > > info so corresponding entries can be added to OneCRL. But, as this is new > > to me, I will appreciate thoughtful and constructive input in this. > > > Since CT is not (yet) compulsory, it seems you probably have to contact all > CAs, doesn't it? Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
