Re: Symantec: Update
On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham wrote: > On 11/05/17 13:02, wiz...@ida.net wrote: > > That said, it is fair point that the plan should spell out what happens if > > symantec does not cooperate. > > I think we should cross that bridge when we come to it, which I hope we > won't. Not that I'm not prepared to cross it, but there's no point > devising plans and writing text in advance for a situation which can be > dealt with when and if it occurs. > > Gerv Better keep your deadlines short then. They seem to be the only times Symantec actually responds to anything asked/said here. :-( CU Hans ___ 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
在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道： > On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: > > >> * 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. > >> > > Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot > > be done for the other two ROOTs as we have not yet applied for the > > inclusion of these two. > > Hi. > > Would you like me to add your other two roots to the list of roots that > are accepted by the Comodo Dodo log? > > If so, please either submit a pull request on GitHub (see > https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two > root certs. > > The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online Hi Rob, Thanks for your kind assistance, we have e-mailed our roots to you for this purpose. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
Cory, from your point of view is there interest in being able to tell Requests "I want the no-compromises trust store" and accept a reduced compatibility in exchange for knowing that you're a little safer ? Right now, as a programmer I have three choices with Requests: Verify=True: The default, the store you've described, based on NSS but lacking its nuance, will be used to perform verification of host certificates Verify='/a/filename': I must maintain my own trust store, which is a huge pain in the backside. Verify=False: All verification is switched off. Here be dragons. In Firefox there is no interest in making users lives more complicated by introducing more decisions. But a programmer writing code with Requests and getting as far as reading the documentation for certifi already _does_ care about these decisions. I'm sure the same is true for programmers in other environments. In contrast to the idea of trying to get other clients to implement all the nuances of Firefox's graduated trust, my idea here is to promote the option of deliberately distrusting CAs entirely in these clients, ahead of any such extreme sanction from Mozilla in Firefox. Mozilla could decide (or not) to add an advisory mark when putting in place a graduated trust and this would mean the maintenance burden to offer both an ordinary and a "no-compromise" trust store with something like Requests would be minimal, just verify=certifi.I_HATE_FUN or whatever. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
I think you left this a bit implicit Cory, so I figured it's worth spelling out: the strength of Mozilla's CA program, as a tool for making the web stronger, comes from having people using it, that's the carrot that forces people to meet our standards (also the fact that as a transparent, root program, we serve as a model for the industry!). If we can get better at including the non-browser clients, who are already using the "raw" trust store, it only strengthens our ability to secure the web -- I think we can all agree that's a good goal :-) As you point out though, a huge challenge, is that historically CA-specific remediations have been unique to the circumstances, which means any remediaton we invent a syntax for may be used only once, and any new CA misbehavior may necessitate a remediation we don't have a syntax for yet. I'm not smart enough to come up with a solution for this, other than that maybe if we repeat the process enough times, we'll eventually standardize on a small set of core remediations -- hopefully we never get there though :-) Alex On Thu, May 11, 2017 at 2:30 PM, Cory Benfield wrote: > > > On 11 May 2017, at 19:27, Gervase Markham wrote: > > > > On 11/05/17 18:05, Alex Gaynor wrote: > >> I don't think Cory's arguing against browsers making use of these types > of > >> remediations, he just wants the non-browser clients to be able to > >> participate as well :-) > > > > Sure. I'm just heading off that argument at the pass :-) > > Yeah, Alex is right. I’m *extremely* supportive of the graduated trust > proposals: indeed, I think MDSP’s behaviour and remedies have been > exemplary. I was just feeling out the possibility of Mozilla turning into a > force multiplier. > > Cory ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
> On 11 May 2017, at 19:27, Gervase Markham wrote: > > On 11/05/17 18:05, Alex Gaynor wrote: >> I don't think Cory's arguing against browsers making use of these types of >> remediations, he just wants the non-browser clients to be able to >> participate as well :-) > > Sure. I'm just heading off that argument at the pass :-) Yeah, Alex is right. I’m *extremely* supportive of the graduated trust proposals: indeed, I think MDSP’s behaviour and remedies have been exemplary. I was just feeling out the possibility of Mozilla turning into a force multiplier. Cory ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 11/05/17 18:05, Alex Gaynor wrote: > I don't think Cory's arguing against browsers making use of these types of > remediations, he just wants the non-browser clients to be able to > participate as well :-) Sure. I'm just heading off that argument at the pass :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On 11/05/17 13:02, wiz...@ida.net wrote: > That said, it is fair point that the plan should spell out what happens if > symantec does not cooperate. I think we should cross that bridge when we come to it, which I hope we won't. Not that I'm not prepared to cross it, but there's no point devising plans and writing text in advance for a situation which can be dealt with when and if it occurs. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 11/05/17 12:46, Rob Stradling wrote: > There's a "Created by" field (Username, Timestamp) and a "Last Modified > By" field (Username, Timestamp) in the CCADB, but neither of these > fields are currently provided in the public CSV reports that Mozilla > publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Cory, > > On 11/05/17 15:21, Cory Benfield wrote: > > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. > > Unfortunately, this is not a good enough reason to remove graduate trust > proposals from our arsenal of possible remedies for issues. Because if > the choice is only "trust everything" or "do not trust anything" from a > particular root, we have no mitigations for the Too Big To Fail problem. > I don't think Cory's arguing against browsers making use of these types of remediations, he just wants the non-browser clients to be able to participate as well :-) > > > If Mozilla is interested in doing a substantial public service, this > situation could be improved by having Mozilla and MDSP define a static > configuration format that expresses the graduated trust rules as data, not > code. > > The trouble with this is that the vocabulary of such a format is almost > unbounded. It effectively has to be code, rather than data, because we > could in the future make any number of rules about certificates based on > any number of criteria. > > So we decided to use English instead, which is why this exists: > https://wiki.mozilla.org/CA/Additional_Trust_Changes > > Gerv > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
Hi Cory, On 11/05/17 15:21, Cory Benfield wrote: > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. Unfortunately, this is not a good enough reason to remove graduate trust proposals from our arsenal of possible remedies for issues. Because if the choice is only "trust everything" or "do not trust anything" from a particular root, we have no mitigations for the Too Big To Fail problem. > If Mozilla is interested in doing a substantial public service, this > situation could be improved by having Mozilla and MDSP define a static > configuration format that expresses the graduated trust rules as data, not > code. The trouble with this is that the vocabulary of such a format is almost unbounded. It effectively has to be code, rather than data, because we could in the future make any number of rules about certificates based on any number of criteria. So we decided to use English instead, which is why this exists: https://wiki.mozilla.org/CA/Additional_Trust_Changes Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, > > I think you've correctly highlighted that there's a problem -- the Mozilla > CA store is "designed" to be consumed from NSS, and CA-specific > remediations are a part of that (hash algorithms, maximum certificate > lifetimes, and any number of other important technical controls). > > Unfortunately, we're currently in a position where near as I can tell, most > code (except Go code :P) making HTTPS requests are using a Mozilla-derived > CA store, and OpenSSL's verifier, which only provides a subset of the > technical controls browsers implement. This is unfortunate, particular > because these clients also do not check CT, so it's entirely possible to > serve them certs which are not publicly visible. In a large sense, browsers > currently act as canaries-in-the-coalmine, protecting non-browser clients. > > Like Cory, I help maintain non-browser TLS clients. To that end, I think > it'd be outstanding if as a community we could find a way to get more of > these technical controls into non-browser clients -- some of this is just > things we need to do (e.g. add hash algorithm and lifetime checking to > OpenSSL or all consumers of it), Yes :) There's a significant amount that needs to happen in the third-party verifiers to understand and appreciate the risk of certain behaviours ;) > other's need coordination with Mozilla's > root program, and I think Cory's proposal highlights one way of making that > happen. Right, but these already flow into the NSS trust store - when appropriate. I'm sure you can understand when a piece of logic is _not_ implemented in NSS (e.g. because it's not generic beyond the case of browsers), that it seems weird to put it in/expose it in NSS :) To be clear: I'm not trying to suggest it's an entirely unreasonable request, merely an explanation of the constraints around it and why the current approach is employed that tries to balance what's right for Mozilla users and the overall NSS using community :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
Ryan, I think you've correctly highlighted that there's a problem -- the Mozilla CA store is "designed" to be consumed from NSS, and CA-specific remediations are a part of that (hash algorithms, maximum certificate lifetimes, and any number of other important technical controls). Unfortunately, we're currently in a position where near as I can tell, most code (except Go code :P) making HTTPS requests are using a Mozilla-derived CA store, and OpenSSL's verifier, which only provides a subset of the technical controls browsers implement. This is unfortunate, particular because these clients also do not check CT, so it's entirely possible to serve them certs which are not publicly visible. In a large sense, browsers currently act as canaries-in-the-coalmine, protecting non-browser clients. Like Cory, I help maintain non-browser TLS clients. To that end, I think it'd be outstanding if as a community we could find a way to get more of these technical controls into non-browser clients -- some of this is just things we need to do (e.g. add hash algorithm and lifetime checking to OpenSSL or all consumers of it), other's need coordination with Mozilla's root program, and I think Cory's proposal highlights one way of making that happen. Alex On Thu, May 11, 2017 at 11:33 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > But if you use the trust database without using NSS, you no longer fit into > any of the assumptions or security models with the discussions here on > m.d.s.p. > > A good example of this would be EKU related misissuance. NSS, like > CryptoAPI and several other platforms, has for the past 15 or so years > enforced a constraint that EKUs in intermediates are subsets of their > issuer's, and can be used to reduce the scope of capabilities for issuance. > > As a result, a certificate with an S/MIME EKU issued from an intermediate > that only has id-kp-serverAuth is not at risk of being trusted for S/MIME. > > In many ways, and across the industry, the trust Store is a function of the > consuming and implementing libraries. As features change and are > implemented - for example, support for Certificate Transparency - that > naturally changes the risk calculus in the trust store. > > That's not to say what you request is apriori unreasonable, simply that > it's unwise, which is why the FAQ covers this - > https://wiki.mozilla.org/CA:FAQ > > There's also the reality that some changes are entirely appropriate for > browser clients, but since Mozilla themselves are not using NSS in > non-browser clients, but are aware that others are, they allow these other > organizations and clients to make the decisions appropriate for their > products and the risks and compatibility issues to their clients. > > The historic process is generally that a change is first made to Firefox, > and then if it is generally desired by the ecosystem, trust status flags > are introduced to NSS and added to the root store and library code. For > example, the constraints for ANSSI followed this pattern. > > Microsoft follows a similar pattern - all "less than trusted" statuses are > captured as extended attributes in the publicly available authroot.stl > > However, for both NSS and CryptoAPI, unless you are using the library > itself to do verification, it's caveat emptor as the consumer. And even if > you are using the library, you still have to be responsible for the > security of your users as relevant to your products needs, and that's > something Mozilla doesn't necessarily have insight into and naturally can't > consider unless you participate here (ideally with commenting on proposals > or sharing what your product would do). Although I suspect since most > non-browser clients are more stable/less likely to update, and have less UI > affordances, the general answer would be biased conservatively towards > doing nothing than the steps necessary to protect browser users. > > On Thu, May 11, 2017 at 7:33 AM Cory Benfield via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote: > > > > > While I’m very supportive of this kind of remediation, it is not a > > remediation that non-browser implementations can follow very easily. For > > example, I run a downstream non-browser HTTP client[1] that by default > uses > > a processed version of the Mozilla CA database[2] to define its list of > > trusted roots. This is very convenient, as it allows me to delegate the > job > > of running a CA program to Mozilla and MDSP, a collection of people much > > better equipped to handle the job. This is a common approach throughout > the > > open source ecosystem: for example, curl also makes available a processed > > version of the Mozilla trust database. > > > > I find it's useful to actually provide the footnotes you say you will: > > > > [1]: http://docs.python-requests.org/en/master/ > > [2]: https://github.com/c
Re: Configuring Graduated Trust for Non-Browser Consumption
But if you use the trust database without using NSS, you no longer fit into any of the assumptions or security models with the discussions here on m.d.s.p. A good example of this would be EKU related misissuance. NSS, like CryptoAPI and several other platforms, has for the past 15 or so years enforced a constraint that EKUs in intermediates are subsets of their issuer's, and can be used to reduce the scope of capabilities for issuance. As a result, a certificate with an S/MIME EKU issued from an intermediate that only has id-kp-serverAuth is not at risk of being trusted for S/MIME. In many ways, and across the industry, the trust Store is a function of the consuming and implementing libraries. As features change and are implemented - for example, support for Certificate Transparency - that naturally changes the risk calculus in the trust store. That's not to say what you request is apriori unreasonable, simply that it's unwise, which is why the FAQ covers this - https://wiki.mozilla.org/CA:FAQ There's also the reality that some changes are entirely appropriate for browser clients, but since Mozilla themselves are not using NSS in non-browser clients, but are aware that others are, they allow these other organizations and clients to make the decisions appropriate for their products and the risks and compatibility issues to their clients. The historic process is generally that a change is first made to Firefox, and then if it is generally desired by the ecosystem, trust status flags are introduced to NSS and added to the root store and library code. For example, the constraints for ANSSI followed this pattern. Microsoft follows a similar pattern - all "less than trusted" statuses are captured as extended attributes in the publicly available authroot.stl However, for both NSS and CryptoAPI, unless you are using the library itself to do verification, it's caveat emptor as the consumer. And even if you are using the library, you still have to be responsible for the security of your users as relevant to your products needs, and that's something Mozilla doesn't necessarily have insight into and naturally can't consider unless you participate here (ideally with commenting on proposals or sharing what your product would do). Although I suspect since most non-browser clients are more stable/less likely to update, and have less UI affordances, the general answer would be biased conservatively towards doing nothing than the steps necessary to protect browser users. On Thu, May 11, 2017 at 7:33 AM Cory Benfield via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote: > > > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. For > example, I run a downstream non-browser HTTP client[1] that by default uses > a processed version of the Mozilla CA database[2] to define its list of > trusted roots. This is very convenient, as it allows me to delegate the job > of running a CA program to Mozilla and MDSP, a collection of people much > better equipped to handle the job. This is a common approach throughout the > open source ecosystem: for example, curl also makes available a processed > version of the Mozilla trust database. > > I find it's useful to actually provide the footnotes you say you will: > > [1]: http://docs.python-requests.org/en/master/ > [2]: https://github.com/certifi/python-certifi > ___ > 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: Configuring Graduated Trust for Non-Browser Consumption
On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote: > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. For > example, I run a downstream non-browser HTTP client[1] that by default uses a > processed version of the Mozilla CA database[2] to define its list of trusted > roots. This is very convenient, as it allows me to delegate the job of > running a CA program to Mozilla and MDSP, a collection of people much better > equipped to handle the job. This is a common approach throughout the open > source ecosystem: for example, curl also makes available a processed version > of the Mozilla trust database. I find it's useful to actually provide the footnotes you say you will: [1]: http://docs.python-requests.org/en/master/ [2]: https://github.com/certifi/python-certifi ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Configuring Graduated Trust for Non-Browser Consumption
All, While this ongoing discussion regarding Symantec is going on, I wanted to chime in quickly to make a suggestion about graduated trust. Many of the proposals that Mozilla, Google, and other teams running CA programs put forward in cases of CA misbehaviour is to transition a CA from “trusted” to “partially trusted”: that is, to explicitly distrust certain CA-issued certificates that would ordinarily be trusted. For example, one of the WoSign remediations was to distrusted new WoSign certificates: that is, certificates whose notBefore date was after a certain date. While I’m very supportive of this kind of remediation, it is not a remediation that non-browser implementations can follow very easily. For example, I run a downstream non-browser HTTP client[1] that by default uses a processed version of the Mozilla CA database[2] to define its list of trusted roots. This is very convenient, as it allows me to delegate the job of running a CA program to Mozilla and MDSP, a collection of people much better equipped to handle the job. This is a common approach throughout the open source ecosystem: for example, curl also makes available a processed version of the Mozilla trust database. Unfortunately, it is currently *not* possible to distribute any kind of partial trust information: that is, tools that consume the Mozilla trust database can only completely trust, or completely distrust, a CA. That means that non-browser tools cannot follow the guidance of MDSP or Mozilla, even though we’d very much like to. In practice, this means that we will almost always continue to trust certificates that browsers would not. This prevents us from providing a unified front on this issue, and also exposes our users to risk from misbehaving CAs that we continue to trust to issue new certificates, even though Mozilla would not. We’d like to follow your lead on this: however, it’s just beyond our resources to keep writing custom code to handle these cases each time they come up. If Mozilla is interested in doing a substantial public service, this situation could be improved by having Mozilla and MDSP define a static configuration format that expresses the graduated trust rules as data, not code. Essentially, a file could exist beside the list of root CA certificates that notes any graduated trust rules (e.g. must have notBefore earlier than x, must contain signatures without these hash algorithms, etc.) that would be used by Firefox to build its graduated trust rules. That file could then be distributed with processed versions of the Mozilla trust database, and tools that are able to understand it could apply the graduated trust rules that Mozilla is applying as well. This is just a suggestion: defining, writing, and maintaining this config file would be a decent amount of work and would provide pretty minimal benefit to Mozilla directly. I wouldn’t be at all surprised to find that this is not something Mozilla is interested in pursuing. However, I think it would be of substantial value to the wider HTTP and TLS community if we were able to form a unified front with Mozilla in trusting CAs. Thanks, Cory ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Hunting for intermediates that still haven't been disclosed to CCADB
Both sets had been publicly disclosed through affirmative publishing in the repositories of the respective CAs--that's probably how your crawler found them, because I don't believe they are issuing SSL/TLS certificates. I thought I had disclosed the ones chaining to the DigiCert Orion Health intermediate a while ago (when I first populated the CCADB with our certificates), but apparently I missed those. The Belgian ones were posted just recently, I believe, because I do try to keep the CCADB up to date. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Rob Stradling via dev-security-policy Sent: Thursday, May 11, 2017 5:47 AM To: Kurt Roeckx ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Hunting for intermediates that still haven't been disclosed to CCADB On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote: > On 2017-05-11 13:07, Rob Stradling wrote: >> It would seem that DigiCert noticed these 19 intermediates appear on >> https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, >> because they've all now been disclosed to the CCADB. >> >> They should've been disclosed some time ago, however. > > Does the CCADB keep track of when something was disclosed? A history? There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ 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: Symantec: Update
> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy > wrote: > > I would appreciate people's comments on the details of the current draft. I don’t think that this proposal goes far enough. Symantec has demonstrated that they have no interested in engaging with the Mozilla community about these issues. Over the past months, dozens of relevant and important questions have been asked of Symantec by community members, and most of them remain unanswered to this day. In most cases, when questions were answered, it was only after setting a deadline, at the last possible moment of that deadline, and in a format that made it very hard to track responses and ask follow-up questions. Given this lack of constructive engagement, the recent request that we “pause” making any decisions, and the breathtaking severity of the issues discovered, I believe that the only objective should be to minimize risk to users of the Mozilla root store by removing the Symantec roots as quickly as possible. Trusted roots are a privilege and a responsibility, not a right, and Symantec has demonstrated that they are not capable of fulfilling that responsibility at this time. With that in mind and taking into account the responses to previous incidents, I believe the following actions should be taken as part of the proposed ‘new PKI’ plan: 1) Immediate removal of EV treatment from all certificates issued by existing Symantec roots. 2) The establishment of a cutoff date a few months from now after which new certificates issued from existing Symantec roots will no longer be trusted based on notBefore. A variant of this is already in the proposal, but the timeline is unclear. 3) Complete removal of existing Symantec roots from the trust store as quickly as possible while limiting user impact, using the Chrome accelerated expiry proposal as a starting point. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
Possibly this is irrelevant, but I have some concerns on how Symantec, it seems to me, is willfully mischaracterizing their certificate compliance issues in their prepared remarks to their investors yesterday.[1] It makes it sound as if there are some generic certificate industry changes that are coming that might affect them. They do not seem willing to accept public responsibility for their actions and compliance failures. "As you may be aware, in late March, Google put forth a proposal that, if implemented, would introduce major changes to the processes and operations that are standard across our industry, including our Certificate Authority business. Since that time, we've been engaged in conversations with Google, Mozilla, and other members of the CA community to seek input on our counter proposal that we believe minimizes business disruption for our customers and improves trust in Symantec's CA business. We believe we will find a mutually agreeable path forward that is in the best interest of our customers, and we expect discussions around our proposal to continue and have factored our current expectations around this headwind into our financial outlook." [1] http://s1.q4cdn.com/585930769/files/doc_financials/2017/Q4/Symantec-4Q17-Prepared-Remarks.pdf On Tuesday, May 9, 2017 at 11:51:33 AM UTC-4, Gervase Markham wrote: > Hi everyone, > > Yesterday was May 8th, which was the day I had said we would stop > discussing my proposal of what to do about Symantec and hand it over to > Kathleen for a decision. This didn't happen for two reasons: I had some > personal things to deal with, and also I think the proposal needs some > modification. > > Mozilla runs an open and transparent root program, and listens to the > voice of its community. And over the past few days it's been clear that > our community is not impressed with Symantec's engagement, or lack > thereof, with this process. I personally am also not impressed with the > way that getting information from Symantec feels like pulling teeth; > questions are answered at the last possible minute, and despite there > being major outstanding problems with compliance to Mozilla's root > program requirements (issue Y), no effort is made from their side to > proactively engage and start to resolve these issues. It is clear from > the issues list that there are a number of serious concerns, and these > are not being engaged with. Despite the fact that there appear to be > numerous under-audited and unaudited publicly-trusted sub-CAs out there, > and this fact has been known for weeks now, Symantec has not said > anything about the situation to Mozilla, either publicly or privately. > Would we find this acceptable in any other CA? > > I am also not happy with simply waiting for the outcome of private > discussions between Google and Symantec in which Mozilla's interests are > not adequately represented. I am keen to move forward, to demonstrate > that delay is not rewarded, and (despite the fact that our process can > be slow) to make sure that timely action is taken based on the results > of our investigations. This is only fair, given that this is what we > have attempted to do for other CAs which we have investigated. We should > treat everyone the same, as far as we can. > > I am therefore proposing the following: > > * Editing the proposal to withdraw the "alternative" option, leaving > only the "new PKI" option. I no longer have confidence that the > alternative option represents an appropriate response. As some have > pointed out, the "documentation" requirement is actually something > Symantec should have done years ago as part of our intermediate > disclosure process, and which other CAs have made great efforts to > comply with already. The "new PKI" option represents the best way to > reduce the risk from Symantec's under-managed and sprawling existing PKI. > > * Engagement here in m.d.s.p. with the community to refine and flesh out > the "new PKI" proposal, based on the Google outline but examining it and > enhancing it to make sure it is practical, both from an implementation > perspective and to reduce disruption to sites as far as possible. > > * Discussions within Mozilla as necessary to make sure the appropriate > parts of the organization are briefed on this process. > > * Submission of the proposal document to Kathleen at the earliest > possible moment to propose that we have that plan approved as our > requirements of Symantec. (The timeline here is dependent on other > moving parts, but as noted above, delay is to be avoided.) > > We may in parallel ask further questions of Symantec, and expect timely > answers (as this is a baseline requirement for participation in our root > program), but this process will not wait around for those answers. > > I will begin work on these tasks tomorrow. > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.
Questions for Symantec (2)
Dear Steve and Rick, This is an official communication from the Mozilla CA program requesting Symantec's answers to the following questions by close of business on Monday 15th May. Your answers will be posted in mozilla.dev.security.policy if you don't put them there yourselves. Your speedy attention is appreciated :-) RAs and EV -- 1) Did any of the RAs in your program (CrossCert and co.) have the technical ability to independently issue EV certificates? If they did not, given that they had issuance capability from intermediates which chained up to EV-enabled roots, what technical controls prevented them from having this capability? 2) We note that all four RAs advertised EV certificates on their websites during 2016[0]. If they did not have direct EV issuance capability, by what mechanism did they provide EV certificates to their customers, and what validation (if any) did Symantec do of data provided by the RAs? Issue Y --- 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign Universal Root Certification Authority") and yet do not have BR audits? 4) These two intermediates have a number of sub-intermediates. Does Symantec agree that not all of these sub-intermediates are within the scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how many are in scope and how many are out of scope? If they are all in scope, why are they not listed in the audit document? 5) A statement from Symantec[2] suggests that customers of your NFSSP program can perform RA duties for the issuance of certs for Windows domain controllers and those RA activities are outside the scope of the audit entirely. Is that correct? Please list all companies or organizations which can issue publicly-trusted SSL/TLS certificates with no audit oversight. 6) "VeriSign Universal Root Certification Authority" is EV-enabled. Are there any mechanisms, technical or otherwise, which prevent NFSSP customers from issuing EV certs by including the Symantec EV OID? 7) Does Symantec agree that Issue Y is very serious? What are Symantec's plans to remedy this? Why have they not been communicated up to now? When will they be executed? Issue L --- 8) During the approximately five years that Symantec cross-signed the Federal PKI, thereby making any certificate within it have a path to trust in Mozilla browsers, which of the following best represented Symantec's understanding of the situation: a) Symantec didn't realise that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers; or b) Symantec knew that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers and didn't realise the implications for your own audits and disclosures and the WebPKI; or c) Symantec knew that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers and did realise the implications, but didn't think it was necessary to tell Mozilla about it ? 9) Do you agree that, during the period of time that Symantec cross-signed the Federal PKI (Issue L), it was technically possible for issuers inside the FPKI to issue EV certs by inserting Symantec's EV OID? Other - 10) If, in the Symantec Issues list or any other document relating to this matter we may publish in future, we have drawn a conclusion or inference about Symantec's PKI, actions or behaviour which is incorrect, we expect you to draw that to our attention, even if the truth is not as favourable to Symantec. Are there any incorrect inferences or conclusions in the Issues List which need to be corrected? 11) As requested in an email to Steve Medin on 5th of May and noted again in an email to Quentin Liu on 10th May, please provide copies of all audits of any type relating to the Aetna and UniCredit GeoRoot intermediates. You may attach them to a Bugzilla bug or place them in another public location and provide the URL. Again, many thanks for your cooperation. Gerv [0] http://web.archive.org/web/20161223000146/http://www.crosscert.com/ http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada [1] The following intermediates, at least, are not listed in that audit as being covered: https://crt.sh/?id=19602740 1, https://crt.sh/?id=19602709, https://crt.sh/?id=19602733 3, https://crt.sh/?id=19602720, https://crt.sh/?id=19602670 5, https://crt.sh/?id=19602679, https://crt.sh/?id=19602705 7, https://crt.sh/?id=19602730 . [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 , section 2, first bullet numbered 2. [3] https://bug1334377.bmoattachments.org/attachment.cgi?i
Re: Symantec: Update
Symantec, in previous blog posts on their site, has indicated that they will support their customers [1]. That said, it is fair point that the plan should spell out what happens if symantec does not cooperate. It seems appropriate to have the plan do what it says -- scheduled phase out of the old roots -- with the same timescale. If symantec does not step up to fill their customer needs, I am sure one or more of their competitors will [and remember all this only applies to symantec customers who need publicly trusted certs... one big appeal of the proposal is that non-public uses can remain unaffected]. As the recent Wosign/Startcom experiences teaches, though, if the CA is not cooperative, it is very important for the browsers to step in with messaging. Not sure what form this would take, since most developers I know do not use beta/nightly versions of browsers, so it would need to be something in actual releases. Perhaps a single line with orange background just below URL box that says "in one month, this site will cease to be trusted by major browsers [click here for why]", or somesuch. With the link being very clear: it is the owner of the website that needs to update their certificate. Just a thought. 1. https://www.symantec.com/connect/blogs/message-our-ca-customers "In the event Google implements its proposal, Symantec will ensure your websites, webservers or web applications continue to work across browsers." On Wednesday, May 10, 2017 at 4:11:59 PM UTC-4, okaphone.e...@gmail.com wrote: > On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham wrote: > > On 09/05/17 16:51, Gervase Markham wrote: > > > * Editing the proposal to withdraw the "alternative" option, leaving > > > only the "new PKI" option. > > > > This has now been done: > > > > https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit# > > > > > * Engagement here in m.d.s.p. with the community to refine and flesh out > > > the "new PKI" proposal, based on the Google outline but examining it and > > > enhancing it to make sure it is practical, both from an implementation > > > perspective and to reduce disruption to sites as far as possible. > > > > I would appreciate people's comments on the details of the current draft. > > Makes sense to me. > > But it does seem to assume that Symantec will cooperate with this. What > happens if they decide not to is less clear. Perhaps it would be a good idea > to indicate which steps will be taken in any case? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. Does the CCADB keep track of when something was disclosed? A history? There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. Does the CCADB keep track of when something was disclosed? A history? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Hunting for intermediates that still haven't been disclosed to CCADB
Yesterday I knocked together a script that: scrapes a URL (or a list of URLs) for certificate files; then attempts to build a trust chain (using https://crt.sh/gen-add-chain) for each certificate found; then submits to some CT logs any trust chains that crt.sh hasn't previously seen. I've thrown the code up on GitHub [1]. Overnight I left certscraper to scrape the following lists of URLs: - the disclosure URLs that CAs provided in response to Mozilla's May 2014 CA Communication [2]. - the CP/CPS URLs currently listed in the CCADB (some of which appear to be repository pages). - the Belgian Government eID repository pages [3]. certscraper found... - 8 DigiCert intermediates (found on [4]) that should've been already disclosed to CCADB, but weren't: https://crt.sh/?id=135966905 https://crt.sh/?id=135966906 https://crt.sh/?id=135966907 https://crt.sh/?id=135966908 https://crt.sh/?id=135970325 https://crt.sh/?id=135970327 https://crt.sh/?id=135970329 https://crt.sh/?id=135970332 - 10 Belgian eID intermediates: https://crt.sh/?id=135626971 https://crt.sh/?id=135626972 https://crt.sh/?id=135626973 https://crt.sh/?id=135626974 https://crt.sh/?id=135626975 https://crt.sh/?id=135626980 https://crt.sh/?id=135626981 https://crt.sh/?id=135626982 https://crt.sh/?id=135626983 https://crt.sh/?id=135626984 Another 1 undisclosed Belgian eID intermediate (https://crt.sh/?id=135002620) had appeared in crt.sh a couple of days earlier. It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. [1] https://github.com/robstradling/certscraper [2] https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml [3] https://github.com/robstradling/certscraper/blob/master/url_lists/belgian_eid.txt [4] https://www.digicert.com/digicert-root-certificates.htm?show=all -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Find a 5-year certificate
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . > > Gerv Wow, embarrassingly weak google-fu on my part... Sorry and thanks! ___ 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
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: * 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. Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be done for the other two ROOTs as we have not yet applied for the inclusion of these two. Hi. Would you like me to add your other two roots to the list of roots that are accepted by the Comodo Dodo log? If so, please either submit a pull request on GitHub (see https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two root certs. The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ 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
Hi Andrew, Thanks for the comments. Please check our following responses. > * Please don't protect your PDFs for printing > We have removed the restrictions on the printing of the PDF documents and re-uploaded them to the BUG, these documents are available at: https://bug1128392.bmoattachments.org/attachment.cgi?id=888 https://bug1128392.bmoattachments.org/attachment.cgi?id=889 https://bug1128392.bmoattachments.org/attachment.cgi?id=8866670 https://bug1128392.bmoattachments.org/attachment.cgi?id=8866671 > * 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. > We have replaced the certificate. Please check. > * 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. > GDCA will not issue corresponding certificates if the "issue", "issuewild"property tags do not contain“gdca.com.cn”. In case the property tag “iodef” is present in the CAA records, GDCA will determine whether or not to issue certificates after communicating with the applicant. > * 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) > As required by Mozilla, CPS V4.5 uses methods documented in section 3.2.2.4 of version 1.4.1 of the CA/Browser Forum's Baseline Requirements (BRs)for domain validation. We will checkBR v1.4.3 and later versions and update this section as necessary. > * 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." > In our next version, we will disclose: “Certificate serial number--Within the domain of each Issuing CA, GDCA includes a unique non-sequential Certificate serial number greater than zerocontaining 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. > Certificates of GDCA's publically trusted CAs do not use sha1RSA signing algorithm. We will definitely disclose in the next version. > * 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. > The content of section 7.1.5 of CP/CPS will be moved to section 3.1.2 in the next version of CP/CPS. And GDCA has no stipulation on 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. > Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be done for the other two ROOTs as we have not yet applied for the inclusion of these two. > * 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. > We have uploaded all the intermediate certificates of the GDCA TrustAUTH R5 ROOT in the CCADB. According to the CCADB rules, CAs can only upload intermediate certificates, and only Root Store Members can upload root certificates, therefore, GDCA has not uploaded the 数安时代R5根CA and the GDCA TrustAUTH E5 ROOTand their respective intermediate certificates. For your information, we expect to publish the next version of our CP/CPS on around May 25, 2017, with the latest comments and BR v1.4.4 taken into consideration. And as always, 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
Re: Find a 5-year certificate
On 10/05/17 18:12, userwithuid wrote: > Limiting to 60 months could be done right now as a sanity check and shouldn't > cause any problems, right? https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
