Re: Audit Letter Validation (ALV) on intermediate certs in CCADB
On Sat, Dec 21, 2019 at 11:30 AM Nick Lamb wrote: > On Thu, 19 Dec 2019 10:23:19 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > We've included a question about complying with the intermediate audit > > requirements in the January survey, but not a more general question > > about exceptions. I feel that an open-ended question such as this > > will be confusing for CAs to answer, and moreover I don't want to > > create the impression that Mozilla grants exceptions for policy > > violations because, as a general rule, we don't. > > As a general rule you don't grant exceptions, and so exceptions are > let's say, an exception to that general rule? Hence the name. > > Nope. The point is that we have no systematic process for handling exceptions, and to the best of my knowledge no list of granted exceptions exists. It's not even clear what constitutes an exception. Is any policy violation an exception? Does a certificate that was misissued 23 months ago but not revoked constitute an exception? Are the Symantec subordinates that are allow-listed exceptions? Is an exception something that a Mozilla representative interpreted for a CA as being permitted? Is an exception narrowly defined as something that Mozilla agreed to in writing? We may have been more liberal in making exceptions in the past, but I have hopefully been consistent in stating that it is the CA's responsibility to decide what to do and inform us rather than ask for permission. So, to the same end as my original proposal, I recommend instead that > Mozilla personalizes any CA survey sent out to a CA which they believe > currently benefits from any such exceptions - setting out what those > exceptions to its rules are for that CA. And in all communications the > text should be clear that any exceptions the CA believed were in place > are in fact spent as far as Mozilla is concerned unless they are > enumerated in this communication. > > This is challenging because no list of exceptions exists and because I'm not aware of a way to perform this type of customization in our survey system (I'll confirm with Kathleen). In the event there are in fact NO exceptions, that's just one small > tweak to the text. > > But potentially a very confusing tweak, unless we define what we mean by an exception. I suggest that we modify question #1 to require CAs to attest that they intend to FULLY comply with version 2.7 of the policy and if they won't fully comply, to list all non-conforrmities. In other words, define an exception as anything that isn't compliant with the current policy rather than something we granted in the past. In the event that one or two CAs benefit from some minor exception > which still has force, it's a little bit of work, and in the process a > firm reminder to both Mozilla and the CA of the ongoing price of such > exceptions. > > Not to mention a good argument that exceptions are unfair. And in the event that it's actually dozens of exceptions across many or > most CAs I hope the realisation of the effort involved will cause Wayne > to reconsider his previous claim that "as a general rule, we don't". > > I agree that it would be valuable to know if this is the case. One valuable opportunity from m.d.s.policy is for CAs to learn from > each others mistakes and in doing so avoid making the same or similar > mistakes themselves. But Mozilla has opportunities to learn from > mistakes here too, and I feel as though the mismatch between Kathleen's > expectation (that a situation should have "resolved" since 2016) and > the CA's understanding (that this constituted an indefinite exception > to Mozilla policy) is such a mistake. > > I agree. > Nick. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2020 CA Communication
On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley wrote: > Should anything be mentioned about the allowed algorithms? That's the > largest change to the policy and confirming the AlgorithmIdentifiers in > each case may take some time. > > I'd argue that this is a clarification rather than a change, and depending on the CA, confirming compliance with the updates in section 5.1 may not take as long as the CPS updates. I'm not strongly opposed to calling this out but I'd argue that it's hard to miss when reviewing all of the updates as required by question #1. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2020 CA Communication
On Thu, Dec 19, 2019 at 3:12 PM Ryan Sleevi wrote: > > On Thu, Dec 19, 2019 at 12:10 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> All, >> >> I've drafted a new email and survey that I plan to send to all CAs in the >> Mozilla program in early January. it focuses on compliance with the new >> (2.7) version of our Root Store Policy. I will appreciate your review and >> feedback on the draft: >> >> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW > > > ## ACTION 1 ## > One thing that I think came up from the past CA communications is that CAs > assert this, but then end up failing to actually implement. > > Perhaps it may be worthwhile to be more explicit here about the > expectations: > > """ > Read version 2.7 of Mozilla's Root Store Policy. > > CAs are expected to review and abide by Version 2.7 of Mozilla's Root > Store Policy. This includes a number of changes from previous versions. CAs > MUST review this policy and ensure compliance, and CAs SHOULD carefully > review the differences from previous versions of Mozilla's Policy. These > changes have been discussed on mozilla.dev.security.policy and on GitHub. > CAs that did not participate in these discussions or that have not yet > reviewed these conversations should also review the discussions regarding > these changes, to reduce the chance of confusion or misinterpretation. > > CAs are encouraged to raise any questions that they do not feel addressed > in the Policy, or which the discussions and reasoning for the changes was > not clear. > """ > > There's probably a better way to word all of this, but where I'm trying to > emphasize > - The policy is the policy, and the ideal goal is that the policy stands > by itself > - That said, CAs understandably can misinterpret new policies when they > use the logic of past policies or interpretations, while someone reading > the policy fresh or which participated in the discussions about the policy > would not be confused by > - Even though CAs are required to follow m.d.s.p., the length of time for > Policy 2.7 may mean they have had turnover or knowledge drain or simply > forgot, so it's good to remind them that they can find information about > each and every change discussed here or on GitHub, and they're expected to > be familiar with it > > I'm trying to flag the "We didn't follow the discussion and continued to > use our old interpretation" scenario, and see if there's something that can > be done to remind folks to pay attention. > > I've incorporated these suggestions. ## ACTION 3 ## > Would it make sense to add a third option, "All end-entity certificates > that we issue or have issued after [date] and are within..." and let folks > specify a date? > > I largely mention this because it's an existing Microsoft requirement as I > understand it, and is somewhat enforced by Apple (at least for TLS) since > July, so it may be that CAs are already compliant for new certificates, but > also have unexpired old certificates that are not compliant. It may be that > the answer is supposed to be "#1", but that wasn't immediately obvious to > me when I first read. > > Alternatively, it might be clearer to reword that "Beginning on 1 July, > 2020, *new* end-entity ...", to emphasize that it's not that > Firefox/Mozilla will begin enforcing on 2020-07-01, but that certificates > issued on/after that date will be required to be compliant (presumably, > measured by notBefore) > > I made both of these changes as well. ## ACTION 5 ## > I'm not sure if Salesforce forms allow it, but is it possible to have > Action 5 include both a date selector and a comment field? It might make it > easier to have consistency for options 3 & 4. Like "ACTION 5 Date" and > "ACTION 5 Comments" > > Of course, if it doesn't, no worries. > I added an optional date entry field to this question. All of these changes are now published at link I shared. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
NYT 12/23/2019 on the ToTok spying app and DarkMatter: -- WASHINGTON — It is billed as an easy and secure way to chat by video or text message with friends and family, even in a country that has restricted popular messaging services like WhatsApp and Skype. But the service, ToTok, is actually a spying tool, according to American officials familiar with a classified intelligence assessment and a New York Times investigation into the app and its developers. It is used by the government of the United Arab Emirates to try to track every conversation, movement, relationship, appointment, sound and image of those who install it on their phones A technical analysis and interviews with computer security experts showed that the firm behind ToTok, Breej Holding, is most likely a front company affiliated with DarkMatter, an Abu Dhabi-based cyberintelligence and hacking firm where Emirati intelligence officials, former National Security Agency employees and former Israeli military intelligence operatives work. DarkMatter is under F.B.I. investigation, according to former employees and law enforcement officials, for possible cybercrimes. The American intelligence assessment and the technical analysis also linked ToTok to Pax AI, an Abu Dhabi-based data mining firm that appears to be tied to DarkMatter. -- https://www.nytimes.com/2019/12/22/us/politics/totok-app-uae.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.7 Published
You can find an explanation of Mozilla's enforcement mechanism on our wiki [1]. When a CA fails to comply, the immediate action upon discovery is the creation of an incident bug and the expectation that the CA will file an incident report [2]. - Wayne [1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement [2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report On Mon, Dec 23, 2019 at 9:24 AM Tomas Hidalgo Salvador via dev-security-policy wrote: > Hi Wayne, > > What could be the consequences of a given CA (Certification Authority) not > complying with this new policy? Thanks! > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.7 Published
Hi Wayne, What could be the consequences of a given CA (Certification Authority) not complying with this new policy? Thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
