Re: Misissuance/non-compliance remediation timelines
On February 9, 2018 at 1:24:12 AM, Wayne Thayer (wtha...@mozilla.com) wrote: On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, how long is too long? > This is the crux of the issue for me. If a CA (that really should have stopped responding 'good' for unknown certs back in 2013) needs to select, purchase, and deploy an entirely new OCSP system, is 5 months a really long time? From their perspective, probably not. I agree that from their perspective that's a short period of time. However, I strongly believe that asking the public to bear the burden of a CA's own incompetence is, while historically what has been done, not tenable moving forward. In the specific case of the OCSP issues I question why we should give CAs half a year to remediate a fault that had already been a requirement for 4 years when it was discovered. In many ways a CA's primary job is knowing and following the rules, so why are we giving CAs who fail in such colossal fashion a free pass? I don't believe there is a standard answer to this question that can apply to a whole class of issues, but I do think we could do a better job of communicating our expectations when a situation like this arises by making a statement such as 'being a CA that has been granted the public's trust, Mozilla expects problem X to be resolved in Y days'. Responsible CAs will meet the deadline and thus distinguish themselves from CAs that simply aren't taking the problem seriously. If Mozilla provides a deadline and a CA misses it, what's the penalty? I believe a graduated notion of penalties and risk mitigation would make it easier for Mozilla to push CAs. If the only penalty is distrust then "little" things like a slow but steady trickle of misissued certificates, operating your OCSP responder out of compliance for 4 years, or failing to get a BR audit for 3 years after they became required never rise to the level of a distrust conversation. If, on the other hand, there exists a set of penalty tiers a CA can be placed on that path relatively quickly. Instead of a "sudden" (from the perspective of the CA or subscribers who aren't engaged with policy discussions on mdsp) distrust thread, there is an escalation that makes everyone aware of a CA's need to shape up. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wyane, > resopnding to your notes: > > Section 4.9 states that in any case that Comsign is notified about a > misissuance (no matter if it was notified by a subscriber or in any other > way) Comsign shall revoke the certificate. > > I have re-read section 4.9 of the ComSign CPS and I still do not agree with your interpretation. However, I also believe that your current language complies with Mozilla policy and the BR's. It is true that we didn’t update the version number and we have corrected > it. Along with updating the CPS version management table as well. > > about the software we use for issuing certificate- As we commented on the > January Communication we didn’t issue any SSL certificate in the last years > at all – we do not plan to issue any SSL certificates in our current RSA > software – only with our new one who is under audit now. > > To recap, this inclusion request is for the ComSign Global Root CA that was created in 2011[1]. This root was first BR audited on 26-April 2015, but 36 end-entity certificates were issued prior to that time [2] (all but one has since expired). We also have some evidence [3] that ComSign received an ETSI 101 456 audit in 2012. ComSign stated “Back then it seems we didn’t have a WebTrust audit (I believe we started in 2015) but only external CPA and governmental audits as are attached already.” However, I am unable to locate any additional audit documentation covering 2011-2015. about the software we use for issuing certificate- As we commented on the > January Communication we didn’t issue any SSL certificate in the last years > at all – we do not plan to issue any SSL certificates in our current RSA > software – only with our new one who is under audit now. > ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to issue certificates. This version has not been supported since July 2013 [4]. This implies that all 36 certificates were issued using unsupported CA software. I’ve discovered that ComSign recently issued two new unconstrained subordinate CAs [5] from this root that contain a non-critical basicConstraints extension in violation of BR 7.1.2.2. Another unconstrained subordinate CA has been used to issue email certificates that contain encoding errors [6]. In addition, numerous problems with ComSign’s CPS have been discussed in this thread. So, like we mentioned earlier we would like to be approved in advance so we > could start issuing as soon as the new system will be in use. > While I appreciate ComSign’s efforts to resolve issues that have been identified, new ones continue to be found. I am not at all comfortable recommending that this request proceed at this time, and I have also lost confidence that trust can ever be established for this root given its history. I support Ryan’s recommendation that this request be denied and that ComSign be asked to submit a new root containing a new key pair that has not been used with their outdated CA system. I would appreciate your comments on this course of action. Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=675060 [2] https://bugzilla.mozilla.org/attachment.cgi?id=8938861 [3] https://bug675060.bmoattachments.org/attachment.cgi?id=615121 [4] https://community.rsa.com/docs/DOC-73367 [5] https://crt.sh/?cablint=680&iCAID=1631&minNotBefore=2017-01-01 [6] https://crt.sh/?caid=14449&opt=x509lint&minNotBefore=2014-01-01 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On Thu, Feb 8, 2018 at 3:14 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 8 Feb 2018 15:50:08 + > Gervase Markham via dev-security-policy > wrote: > > > In this case, the certificates are revoked in Firefox via OneCRL and > > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be > > noticed. > > Hi Gerv, > > Independent of this specific case, which I guess is mostly harmless, I > find this worrying. > > Let's assume something like this happens: > * CA xyz, which is trusted by Mozilla and other root stores, issues a > sub-certificate for company SuperShady Inc. Immediately after that > CA xyz asks Mozilla to include it into OneCRL and Google to include > it in CRLsets. > * SuperShady Inc. starts selling certificates. Their offer is that you > can get a certificate for every domain you want, the price depends on > how popular the domain is. If you pay enough you can get a > certificate that's valid for google.com or facebook.com. > * SuperShady Inc. advertises their certificates with the fact that > while they won't be valid in mainstream browsers due to revocation > lists they still work in many situations, i.e. they will be > considered valid by commandline tools or API calls from many > programming languages as they don't include a mechanism like OneCRL. > > I'm aware that this goes into the tricky topic of people consuming the > Mozilla CA root store without implementing the full certificate > validation logic, which is already a problem with deprecated CAs like > the old Symantec roots that are phased out. > But this is much more sever. While we don't expect that the > Symantec roots have been operated with the care we expect from a CA we > also don't have any indication that they're used for outright malicious > purposes. > > Yet I feel what you and others here are implying is that once a subca > is part of OneCRL and revoked they're no longer bound to any standards > at all. > How is this different from CA xyz asks for their root to be removed from Mozilla products and other root stores, but applications and devices use older versions? The simple answer is that those commandline tools and API calls for programming language are responsible for their application security. They always have been. They don't get a free pass now. A root store is as much a product decision as the choice of programming language to write it in. The same argument you're making here is if CA xyz revokes SuperShady Inc's certificate. The same commandline tools and APIs for programming languages don't do revocation checking (often times because their design is such that it's impossible for them to do so, because making network requests is the caller's job or shouldn't be done in the batch processing) We've had the discussion on m.d.s.p. in a variety of ways in the past regarding consumption of the root stores and program decisions. There's even a FAQ about it to cover this question which is periodically raised, as it is now - https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F """Therefore, anyone considering bundling Mozilla's root store with other software needs to be aware of the issues surrounding providing a root store, and committed to making sure that they maintain security for their users by carefully observing Mozilla's actions and taking appropriate steps of their own. On a best-efforts basis, Mozilla maintains a list of the additional things users of our store might need to consider. """ OneCRL is a way that attempts to address impact and risk for Mozilla Firefox users. It is not inherently going to be guaranteed to be appropriate for other use cases - each application vendor needs to evaluate their community of users, the expectations, the stability contracts, the impacts, etc when it decides to handle revocation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On Thu, 8 Feb 2018 15:50:08 + Gervase Markham via dev-security-policy wrote: > In this case, the certificates are revoked in Firefox via OneCRL and > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be > noticed. Hi Gerv, Independent of this specific case, which I guess is mostly harmless, I find this worrying. Let's assume something like this happens: * CA xyz, which is trusted by Mozilla and other root stores, issues a sub-certificate for company SuperShady Inc. Immediately after that CA xyz asks Mozilla to include it into OneCRL and Google to include it in CRLsets. * SuperShady Inc. starts selling certificates. Their offer is that you can get a certificate for every domain you want, the price depends on how popular the domain is. If you pay enough you can get a certificate that's valid for google.com or facebook.com. * SuperShady Inc. advertises their certificates with the fact that while they won't be valid in mainstream browsers due to revocation lists they still work in many situations, i.e. they will be considered valid by commandline tools or API calls from many programming languages as they don't include a mechanism like OneCRL. I'm aware that this goes into the tricky topic of people consuming the Mozilla CA root store without implementing the full certificate validation logic, which is already a problem with deprecated CAs like the old Symantec roots that are phased out. But this is much more sever. While we don't expect that the Symantec roots have been operated with the care we expect from a CA we also don't have any indication that they're used for outright malicious purposes. Yet I feel what you and others here are implying is that once a subca is part of OneCRL and revoked they're no longer bound to any standards at all. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: > >> On 08/02/18 13:47, Hanno Böck wrote: >> >> OneCRL additions normally have an associated bug but I can't see one for >> this... >> > > https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed) > suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467. > > This bug explains the recent addition of this subordinate CA to OneCRL: https://bugzilla.mozilla.org/show_bug.cgi?id=1397969 Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissuance/non-compliance remediation timelines
On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, how long is too long? > This is the crux of the issue for me. If a CA (that really should have stopped responding 'good' for unknown certs back in 2013) needs to select, purchase, and deploy an entirely new OCSP system, is 5 months a really long time? From their perspective, probably not. I don't believe there is a standard answer to this question that can apply to a whole class of issues, but I do think we could do a better job of communicating our expectations when a situation like this arises by making a statement such as 'being a CA that has been granted the public's trust, Mozilla expects problem X to be resolved in Y days'. Responsible CAs will meet the deadline and thus distinguish themselves from CAs that simply aren't taking the problem seriously. Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: On 08/02/18 13:47, Hanno Böck wrote: Is a revoked intermediate cert a license for operating a yolo CA that signs everything? Given the fragility of revocation checking I'd find that a problematic precedent. In this case, the certificates are revoked in Firefox via OneCRL and Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be noticed. The OCSP seems operational and replies with "Good" and the issuance happened before it's being added to OneCRL. If the cert itself has not been revoked by its issuer, "Good" is an entirely reasonably response... I don't find a reference why this intermediate had been added to OneCRL, but I think this deserves more clarification what's going on here. OneCRL additions normally have an associated bug but I can't see one for this... https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed) suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467. -- Rob Stradling Senior Research & Development Scientist ComodoCA.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On 08/02/18 13:47, Hanno Böck wrote: > Is a revoked intermediate cert a license for operating a yolo CA that > signs everything? Given the fragility of revocation checking I'd find > that a problematic precedent. In this case, the certificates are revoked in Firefox via OneCRL and Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be noticed. > The OCSP seems operational and replies with "Good" and the issuance > happened before it's being added to OneCRL. If the cert itself has not been revoked by its issuer, "Good" is an entirely reasonably response... > I don't find a reference why this intermediate had been added to > OneCRL, but I think this deserves more clarification what's going on > here. OneCRL additions normally have an associated bug but I can't see one for this... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissuance/non-compliance remediation timelines
On 07/02/18 15:14, Alex Gaynor wrote: > That said, given the issues Paul highlighted in his original mail (which I > wholeheartedly concur with), it seems the place to focus is the folks who > are getting Ds right now. Therefore I think the essential part of your > email is your agreement that CAs which are persistently low performing need > to be recognized and potentially penalized for the sum total of their > behaviors. This is, in a reasonably strong sense, what happens now. We require each incident in which a CA is involved to be documented in a public bug, so all can see the timeline, outcomes, how the CA reacted and other factors which might be taken into account when determining a CA's competence. Occasionally, we decide that some CA's list of recent[0] problems is sufficiently serious[0] that we need to run an investigation. We do so, and invite the CA to more formally comment on the sum total of the problems. We assess the responses and the style and level of response, and make a determination[0]. This is what happened to WoSign, Symantec and PROCERT: https://wiki.mozilla.org/CA:WoSign_Issues https://wiki.mozilla.org/CA:Symantec_Issues https://wiki.mozilla.org/CA:PROCERT_Issues I therefore expect and hope that CAs in our program have noted what happened in those cases, particularly PROCERT (which is probably the clearest case of simple "general incompetence" that we have had), and want to make sure they are not next. Gerv [0] Yes, this is vague. But so is the concept of "trust". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
Also, it should be understood that on Linux OS no transitional periods will be made, but simply to removes all Symantec certificates from a certain date. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote: > The subCAs that we know of that fall into this category belong to Google > and Apple. If there are any other subCAs that fall into this category, > please let us know immediately. Google has one such subCA; Apple has seven. Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted on 2017-10-17, has Mozilla learned about any additional subCAs that will require a similar treatment? I assume that the end of the primary development phase for Firefox 60, which is early March 2018, will be the deadline to add whitelisting for any such subCAs. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 20:26, Eric Mill via dev-security-policy wrote: > Adding code to Firefox to support the distrust of specified subCAs seems > like it would be a good long-term investment for Mozilla, as it would give > Mozilla a lot more flexibility during future distrust events. I think this isn't about distrust of specified subCAs, but rather about keeping subCAs actively trusted, despite their issueing roots being no longer trusted. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
Hi, On Tue, 6 Feb 2018 16:56:48 +0100 Kurt Roeckx via dev-security-policy wrote: > I should probably more clear, the certificates of the CA have been > revoked. I'm wondering what that means. Is a revoked intermediate cert a license for operating a yolo CA that signs everything? Given the fragility of revocation checking I'd find that a problematic precedent. The OCSP seems operational and replies with "Good" and the issuance happened before it's being added to OneCRL. I don't find a reference why this intermediate had been added to OneCRL, but I think this deserves more clarification what's going on here. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 19:33, Gervase Markham via dev-security-policy wrote: > As per previous discussions and > https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was > reached among multiple browser makers for a graduated distrust of > Symantec roots. > > Here is Mozilla’s planned timeline for the graduated distrust of > Symantec roots (subject to change): > > * January 2018 (Firefox 58): Notices in the Developer Console will warn > about Symantec certificates issued before 2016-06-01, to encourage site > owners to migrate their TLS certs. > > * May 2018 (Firefox 60): Websites will show an untrusted connection > error if they have a TLS cert issued before 2016-06-01 that chains up to > a Symantec root. My understanding is, this will be done without making any changes to the Mozilla CA list. Firefox will implement these initial phases by changing its certificate validation code. It seems likely that many other consumers of the Mozilla CA list, which use their own implementation for certificate validation, will likely not implement these initial phases. I'm probably stating the obvious. I'd like to thank the developers who can implement this initial distrust phase in their software, as it will clear the way for the later phase of distrust, benefitting other TLS client software which cannot easily implement the initial phases. > * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with > caveats described below. This is the milestone that will affect also the secondary consumers of the Mozilla CA list. I assume the updated CA list with the removed Symantec roots will be published as part of NSS 3.39 around mid October. > However, there are some subCAs of the Symantec roots that are > independently operated by companies ... [snip] ...> There are two ways that > we can provide a smoother transition for these > subCAs. I haven't seen a follow up message with a decision on this detail. I assume it's still open for discussion. > Option 1) > Temporarily treat these subCAs as directly-included trust-anchors. > ... [snip] > > Option 2) > Add code to Firefox to disable the root such that only certain subCAs > will continue to function. So, the final dis-trust of Symantec roots may > actually involve letting one or two of the root certs remain in > Mozilla’s trust store, but having special code to distrust all but > specified subCAs. ... [snip] I assume that these subCAs are used on the public web. IIUC, after secondary consumers of the Mozilla CA list update to the newer version, they will also require a solution that allows them to continue to trust these subCAs. Option 2 solves the issue for Firefox, but it isn't a practical solution for secondary consumers of the Mozilla CA list. There are too many implementations of certificate validation, and I think it's unrealistic that each implementation can implement Option 2. Without implementing option 2, but to keep compatibility with the public web, those secondary consumers would have to modify the Mozilla CA list. There's risk they might decide to continue to trust the Symantec CAs, as that would be the easiest and most compatible approach. I think we should avoid that secondary consumers might consider this solution, as it would be counterproductive to this initiative. I understand that secondary consumers of the Mozilla CA list aren't the primary focus of Mozilla and of this policy list, but in the interest of applying the Symantec distrust initiative to the majority of the open source software ecosystem, it might be prererable to implement Option 1 in the Mozilla CA list. Gerv mentioned the following concerns on Option 1: > Mozilla prefers *not* to take this approach, because even if clearly > explained up front that it is a temporary solution with deadlines, it > would be very easy for people to start treating such a subCA as a > regular trust anchor, and thereby have that subCA become a de facto > included CA. If consumers of the Mozilla CA list usually followed Mozilla's removal decisions, why would they not follow Mozilla's removal of these CAs at a later time? Why would this be more risky than Option 2? Couldn't we similarly argue, if a secondary consumer of the Mozilla CA list decided to implement whitelisting of these subCAs in their certificate validation code, isn't there similar risk that they wouldn't remove such whitelisting from their code? I'd even argue that a code implementation has a higher risk of surviving for a longer amount of time, because changing code is more difficult than changing configuration files that contain a list of trusted CAs. > Additionally, it could become very complicated to remove > such subCAs in the future, especially if they have not performed the > recommended transitions. This message was sent in October 2017. By the time we reach October 2018, the owners of the subCAs will have known about the need to transition away from the classic Symantec PKI for one year. In the cas
Re: Statement on DigiCert’s Proposed Purchase of Symantec
On 01.11.2017 00:58, Jeremy Rowley via dev-security-policy wrote: > A couple of points of clarification (as it seems to have stirred some > questions) > 1. Migration to the DigiCert issuing and validation process only applies to > certs intended for browser use, meaning the infrastructure may issue code > signing, email, etc certs post Dec 1. These certs will be validated and > issued from existing Symantec infrastructure using Symantec validation > processes, at least until we finish migration to DigiCert. > 2. When I refer to "infrastructure" I mean Symantec's validation and issuing > systems related to TLS certificates. We may reuse the front end systems and > hardware used to provide these systems post day 1. Note that we definitely > plan to migrate customers to a consolidated experience, but I want to be > clear and transparent about what is migrating when. Dec 1 is only the TLS > backend. Jeremy, you said the classic Symantec infrastructure may continue to be used for email certificates. Because Mozilla maintains trust flags for email security, I conclude that some of the Symantec Root CAs cannot be removed from the CA list in October 2018 for Firefox 63, but rather they will have their web site trust bit removed, only. Is this correct? If yes, what is the subset of Root CAs that are used for email and must continue to be included as trusted for email? Is that subset equivalent to the set of CAs that currently have the email trust bit enabled? Is there a schedule for the removal of Symantec's email trust bits, or do you assume that the relevant set of Symantec Root CAs will need to be trusted for email until they expire? (Because code signing trust is no longer part of the Mozilla CA store, the continued issueing of code signing certs using Symantec infrastructure seems irrelevant for the Mozilla trust store.) Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy