DigiCert .onion certificates without Tor Service Descriptor Hash extension
In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate convey hashes of keys related to .onion addresses." This language was added in Ballot 201 [2], which had an effective date of 8 July 2017. The following certificates (and precertificates if the corresponding certificate is not in a public CT log) were issued by DigiCert after 8 July for .onion domains, but lack the necessary extension: https://crt.sh/?q=240277340 (revoked 26 October 2017) https://crt.sh/?q=261570255 https://crt.sh/?q=261570338 https://crt.sh/?q=261570380 https://crt.sh/?q=261570384 https://crt.sh/?q=261579788 https://crt.sh/?q=261601212 https://crt.sh/?q=261601280 https://crt.sh/?q=261601281 https://crt.sh/?q=261601284 https://crt.sh/?q=261988060 https://crt.sh/?q=326491168 https://crt.sh/?q=326830043 https://crt.sh/?q=328308725 https://crt.sh/?q=328961187 https://crt.sh/?q=329559222 https://crt.sh/?q=330180704 https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to DigiCert) This was previously discussed on m.d.s.p about a year ago [3]. [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.8.pdf [2] https://cabforum.org/2017/06/08/2427/ [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNID_xfAgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Sat, Mar 10, 2018 at 7:03 PM, syrine.tl--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Trusting a CA is like that. Operating a CA requires a high degree of > > competence and excellence, and each CA applying for inclusion should be > as > > or more competent, as or more skilled, and as or more valuable, as they > > otherwise bring the ecosystem down rather than lifting it up. > > your effort lifting up CA ecosystem will not pay off by rejecting new CA > application. > Sure it is, when the CA has a pattern of misissuance. > You should also consider rejecting trusted CAs that still have > miss-issuance concerns despite their well-established certificate issuance > process and this is a fact. You have much more renewal request than new > inclusion > That has happened as well - if you look at PROCert for example. > If you do have a list of unacceptable auditors, it should be clearly > stated in Mozilla Policy so that all CAs will be informed. > Running through the archives is not considered an appropriate way of > information for a selection process as demanding as this. > This is covered in Section 2.3 of the Policy. > Having a fair and objective process requires applying the same acceptance > or rejection criteria to all CAs. > Otherwise it will be a double standards process. > Section 7.1 of the policy covers this. ""We will determine which CA certificates are included in Mozilla's root program based on the benefits and risks of such inclusion to typical users of our products. "" Inclusions are not guaranteed - they are a balancing act of risk. ""We will make such decisions through a public process, based on objective and verifiable criteria." It is objective and verified that the Tunisian Government has had a problematic series of misissuances, up to and including this past month, and has consistently failed to ensure proper controls are in place. Further, it is objective and verifiable, these were readily detectable by the Tunisian Government, but weren't noticed as such until the issue was raised. These included issues after the Tunisian Government reported them remediated. Further, based on does not mean limited to. ""We reserve the right to not include certificates from a particular CA in our root program."" Any root request can be rejected, for any reason, or not reason at all, at any time. > Anyway, we are looking forward to get the official outcome of Mozilla, and > we will spare no effort to be listed among Mozilla Trusted CA Can you explain your motivations for this? Such a globally trusted root carries with it profound security risk to the ecosystem. What is the overall goal for such trust, given that it does not in any way reduce risk of distrust. If anything, it increases the risk for all Subscribers and Relying Parties, given the pattern of misissuances shown and the apparent lack of technical expertise to support and protect that infrastructure. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Sat, Mar 10, 2018 at 2:55 PM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > > just I want to remind you of these discussion and your opinion below > in some was different than you say here !!! > > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/CfyeeybBz9c > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/K3sk5ZMv2DE > > and > https://misissued.com/batch/1/ > > can you explain please > Anis I already have, but it seems you don't understand how a pattern of misissuance is problematic. I'm glad you agree that there's a pattern of misissuance, though - it does make it much easier to argue that the CA should not be trusted when there's agreement that they're not able to adhere to the Baseline Requirements. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Following up on Trustico: reseller practices and accountability
Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the following email to its partner ecosystem: Dear Partner, In reaction to current events related to the private key exposure and mass revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted Partners and Resellers to survey how they approach customer private key and CSR generation. The most secure method is to generate the keys on the server and then use the CSR when requesting the certificate. If you do generate private keys for any of your customers outside of the web server environment where the certificate will be hosted, we request that you stop this practice immediately. We ask that all Partners and Resellers complete the following short questionnaire as soon as possible or by: Friday, March 16, 2018. Compliance questionnaire : [REDACTED] Note: Only one questionnaire needs to be completed per company. Thank you in advance for your cooperation and attention to this important topic. Kind regards, GlobalSign Security and Compliance So it's nice to see that at least one CA is taking action on this topic without being ordered to (that I'm aware of). Obviously not all resellers are like Trustico and perform only a straight certificate pass-through, as Ryan Sleevi pointed out, and key escrow is a necessary part of acting as a host, or CDN, or other authorized representative. But surely there is still some way to responsibly look through the ecosystem for resellers that do not perform an authorized function that requires key escrow. Are any other CAs willing to do something like GlobalSign has done? Also, it would be very helpful if GlobalSign could share some information relating to the responses they get, even if they are aggregated or anonymized. -- Eric On Sun, Mar 4, 2018 at 4:04 PM, Eric Mill wrote: > Last week, Trustico (a reseller, formerly for Symantec and now for Comodo) > sent 23,000 private keys to DigiCert, to force their revocation. This > showed that Trustico had been storing customer keys generated through one > or more CSR/key generation forms on their website. > > Though Trustico disagrees, this appears to be a clear case of routine key > compromise for subscribers who obtained their key from Trustico. The > security of Trustico's systems, which are not audited or accountable to > root program requirements, were storing large amounts of key material whose > compromise could have led to the subsequent compromise of connections to > tens of thousands of online services. > > It was also noted that Trustico was exposing key material to interception > by a number of third parties through client-side JavaScript embeds, and > that Trustico's website had functionality that allowed remote code > execution as root on one of their web servers. > > These m.d.s.p threads document/link to those things: > > * https://groups.google.com/d/topic/mozilla.dev.security. > policy/wxX4Yv0E3Mk/discussion > * https://groups.google.com/d/topic/mozilla.dev.security. > policy/BLvabFwcJqo/discussion > > As part of the second thread, Comodo noted: > > We also asked Trustico to cease offering any tools to generate and/or > retain customer private keys. They have complied with this request and > have confirmed that they do not intend to offer any such tools again in the > future. > > > That is good to hear, but a "we won't do it again" response, if accepted > by Comodo as sufficient, seems disproportionate to the severity of the > issue, given Trustico's unfamiliarity with norms around private key > management, and with basic security practices. > > It's also clear from the experience that rules of the road for resellers > are unclear, and that accountability is limited. It seems possible, or > likely, that other resellers may also be mishandling customer keys > > So, what would useful next steps be to improve security and accountability > for resellers? > > One thought: Mozilla could ask CAs to obtain a written response from all > contracted resellers about if/how they interact with customer key material, > including the level of isolation/security given their key generation > environment (if they have one), and whether any third-party JavaScript is > given access to generated key material. > > Any other ideas? > > Also -- Comodo noted: > > Trustico have also confirmed to us that they were not, and are not, in > possession of the private keys that correspond to any of the certificates > that they have requested for their customers through Comodo CA. > > > Since there appears to have been a significant overlap period, between the > time Trustico switched to Comodo and when Trustico was asked by Comodo to > cease key storage practices, it's a little hard to take at face value the > assurance that Trustico was never in possession of any Comodo keys. It > would be nice to hear something from Comodo about whether they've verified > this in any more detail. > > -- Eric > > -- > konklone.com | @konklone
