Mozilla CA Policy 2.4 RC1, and timing
Hi everyone, We've now worked our way through all 21 issues which were scheduled for Mozilla CA Policy 2.4. You can see the current text here: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md https://github.com/mozilla/pkipolicy/blob/master/ccadb/mozilla.md This message is: 1. A last call for suggested updates which fit the original 2.4 criteria of "either urgent, or relatively uncontroversial and self-contained". 2. A request that people review the document to make sure nothing untoward has crept in. You can see a diff from 2.3 and a list of commits here: https://github.com/mozilla/pkipolicy/compare/2.3...master The CCADB policies are new in 2.4 and so there is no diff. 3. The start of a discussion on implementation timings. I would like most of the changes to apply immediately, but I would like CAs to suggest which changes (and why) might need a phase-in period. Changes which I have identified that might be in this category are: * Require full CP/CPS in English (proposal: 3 months) I hope to finalise policy 2.4 by the end of the month. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
On 16/02/17 18:26, blake.mor...@trustis.com wrote: > Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com > and replaced it with a SHA-256 Certificate. This status is reflected > in the latest CRL. Hi Blake, We are pleased to hear that, but the detail of your report compares somewhat unfavourably with that of QuoVadis, about whom a similar problem was raised in the same timeframe. You can find their report here: https://groups.google.com/d/msg/mozilla.dev.security.policy/xxtUlTOo6ak/XX6WqlEmEQAJ We would appreciate it if Trustis could produce a similar document within the week. Many thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 23:53, Wayne Thayer wrote: > Gerv - this makes sense and it is GoDaddy's intent to perform these steps > within 3 months. No significant objections have been put forward about this action plan, and so I have filed a Bugzilla bug to track GoDaddy's implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1341014 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.4 Proposal: Update algorithms and key sizes list
On 07/02/17 17:45, Gervase Markham wrote: > We want to update the permitted algorithms and key sizes list. Resolution: resolved as specced (using English descriptions rather than AlgorithmIdentifiers). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban
On 07/02/17 17:25, Gervase Markham wrote: > Therefore, we would like to update Mozilla's CA policy to implement a > "proper" SHA-1 ban. Resolution: resolved pretty much as drafted. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January 2017
Hi Stephen, On 16/02/17 18:37, Stephen Davidson wrote: > Incident Report Thank you for your prompt and detailed incident report. It seems to me that this highlights the particular extra care that needs to be taken by all CAs regarding manual issuances which do not use the normal software into which checks are built. Group participants: would it make sense for the next CA Communication to remind CAs of this, pointing at the cablint tool as something they could run over manually-issued certs before distributing them to make sure no rules were accidentally broken? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
On 24/02/17 07:08, blake.mor...@trustis.com wrote: > Certificates for the HMRC SET Service are issued from the SHA-1 “FPS > TT Issuing Authority”, which is now only used for this service. The > replacement server certificate for hmrcset.trustis.com was issued > from the FPS TT IA, via a manual process under the mistaken belief > that this was necessary for this particular service to operate > correctly. And presumably under the further mistaken belief that "necessary for this particular service to operate correctly" was a good enough reason to disregard the SHA-1 ban? > Trustis has some time ago, migrated all TLS certificate production to > SHA-256 Issuing Authorities. The small number of previously issued > SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes > extending beyond 1 Jan 2017, were revoked towards the end of 2016. Except the one in use on hmrcset.trustis.com? It's not clear how the certificate-nearing-expiry for that domain fits into the last sentence of the paragraph above. > As a result of the investigation the security management committee > has made a number of recommendations. Principal amongst these is > enhanced training and oversight for technical staff that deal with > unique certificates or certificate management in complex > circumstances that are not part of standard operations. Have you deleted, locked or otherwise made unavailable all SHA-1 profiles which relate to intermediates which chain up to publicly trusted roots? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist
On 22/02/17 17:08, Richard Wang wrote: > I think "apple-id-2.com" is a high risk domain that must be blocked to issue > DV SSL to those domains. I don't represent Let's Encrypt, but their policy on such things is relevant to this discussion, and it is here: https://letsencrypt.org/2015/10/29/phishing-and-malware.html Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist
On 22/02/17 14:42, Tony Zhaocheng Tan wrote: > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. > However, until today, the domain apple-id-2.com has apparently never > been registered. How was the certificate issued? On Hacker News, Josh Aas writes: "Head of Let's Encrypt here. Our team is looking into this and so far we don't see any evidence of mis-issuance in our logs. It looks like the domain in question, 'apple-id-2.com', was registered and DNS resolved for it successfully at time of issuance. Here is the valid authorization record including the resolved IP addresses for 'apple-id-2.com': https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl... We can't be sure why the reporter was unable to find a WHOIS record, we can only confirm that validation properly succeeded at time of issuance. Update: Squarespace has confirmed that they did register the domain and then released it after getting a certificate from us." There is currently an entry in WHOIS, because some well-meaning but unhelpful person registered it today. I assume that if a domain is registered and then released, and then re-registered, the "Creation" date is of the re-registration, not the first ever registration. So unless someone can show it was unregistered at the time of issuance, I don't see an issue here. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 14:34, Nick Lamb wrote: > I don't think Ballot 169 represents best practices per se. Instead as > with the rest of the Baseline Requirements what we have here are > _minimums_, we aren't asking that CAs should do no more than what is > described, but that they must do at least what is described. Well, OK. That wasn't really the focus of the statement. I suspect that the ballot 169 methods are bar-raising for most CAs, even if they aren't yet as watertight as they could be. > Anyway, I have a nitpick for your GoDaddy remediation plan. I think > in item (1) it's not clear that it's fine for a CA to choose to > implement many or even all ten methods, and even for them to have > other methods - what's important is that for any particular name > validated their process ensures at least one of the ten Ballot 169 > methods was used. That is my intent; I'm happy to make that clear. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 16:41, Nick Lamb wrote: > GoDaddy came up with). Thus, even though some of the methods from > Ballot 169 are not included in the Baseline Requirements today, > Mozilla intends to oblige root programme members to pick from those > ten methods. Yes. And this is permitted by the BRs because they currently have an "any other method" method, which could cover any of the ones whose actual text is missing. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 13/02/17 14:34, Doug Beattie wrote: > This was for GlobalSign account used for testing, so it was a > GlobalSIgn employee. Customers are not, nor have they ever been, > permitted to add domains without GlobalSign enforcing the domain > verification process. OK, then I'm a bit confused. You say this was a "managed service account"; does such an account belong to a customer? If so, let's call them company Foo. > 9/11/2015 11:41:20 - test.com added as a prevetted domains i.e. a GlobalSign employee added test.com to the account of company Foo. > 9/11/2015 11:50 - Order received by CA i.e. Company Foo places an order for a test.com cert. (You say "received", so it didn't come from internally?) How did Company Foo know it was OK to order such a cert? And why would they do so? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Taiwan GRCA Root Renewal Request
On 11/02/17 12:13, Peter Gutmann wrote: > Is no-one at Mozilla able to explain why they did this? It's a nontrivial > piece of code to implement, surely someone must know what the thinking was > behind doing it this way? Peter: you are going to have to re-summarise your question. And then, if you are asking why Mozilla code works in a certain way, mozilla.dev.security or mozilla.dev.tech.crypto are almost certainly far better venues. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On 10/02/17 06:15, Richard Wang wrote: > I think Mozilla should have a very clear policy for: > (1) If a company that not a public trusted CA acquired a trusted root key, > what the company must do? > (2) If a company is a public trusted CA that acquired a trusted root key, > what the company must do? > (3) If a company is a public trusted CA, but distrusted by Mozilla, this > company acquired a trusted root key, what the company must do? We do: https://wiki.mozilla.org/CA:RootTransferPolicy . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On 09/02/17 14:32, Gijs Kruitbosch wrote: > Would Mozilla's root program consider changing this requirement so that > it *does* require public disclosure, or are there convincing reasons not > to? At first glance, it seems like 'guiding' CAs towards additional > transparency in the CA market/industry/... might be helpful to people > outside Mozilla's root program itself. This would require CAs and companies to disclose major product plans publicly well in advance of the time they would normally disclose them. I won't dig out the dates myself, or check the emails, but if you look for the following dates from publicly-available information: A) The date Google took control of the GlobalSign roots B) The date Google publicly announced GTS you will see there's quite a big delta. If you assume Google told Mozilla about event A) before it happened, then you can see the problem. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On 10/02/17 05:10, Peter Bowen wrote: > On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via >> A) The date Google took control of the GlobalSign roots >> B) The date Google publicly announced GTS >> >> you will see there's quite a big delta. If you assume Google told >> Mozilla about event A) before it happened, then you can see the problem. > > Google says they took control on 11 August 2016. So that's date A). > On 19 October 2016, Google publicly stated "Update on the Google PKI: > new roots were generated and web trust audits were performed, the > report on this is forthcoming," > (https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google) Then you can consider this as Date B) :-) > I appreciate the business realities of pre-disclosure, but that is not > the case here. There is no excuse for having taken control of > existing roots and not disclosing such once they disclosed that they > are intending to become a root CA. This may or may not be what people think the policy _should_ be, but the policy currently _is_ that disclosures of ownership change do not have to be public. Mozilla does not require public disclosure of change of ownership at any time. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Hi Ryan, On 09/02/17 19:55, Ryan Hurst wrote: > - The EV OID associated with this permission is associated with GlobalSign > and not Google and, Which EV OID are you referring to, precisely? > - GlobalSign is active member in good standing with the respective root > programs and, > - Google will not be issuing EV SSL certificates, > - Google will operate these roots under their own CP/CPS’s and associated > OIDs, > - Google issuing a certificate with the GlobalSign OIDs would qualify as > miss-issuance. > > That it would be acceptable for us not to undergo a EV SSL audit, > and that GlobalSign could keep the EV right for the associated subordinate > CA for the remaining validity period to facilitate the transition > (assuming continued compliance). Just to be clear: GlobalSign continues to operate at least one subCA under a root which Google has purchased, and that root is EV-enabled, and the sub-CA continues to do EV issuance (and is audited as such) but the root is no longer EV audited, and nor is the rest of the hierarchy? > When looking at this issue it is important to keep in mind Google has > operated a WebTrust audited subordinate CA under Symantec for quite a > long time. As part of this they have maintained audited facilities, > and procedures appropriate for offline key management, CRL/OCSP > generation, and other related activities. Based on this, and the > timing of both our audit, and key transfer all parties concluded it > would be sufficient to have the auditors provide an opinion letter > about the transfer of the keys and have those keys covered by the > subsequent annual audit. Can you tell us what the planned start/end dates for the audit period of that annual audit are/will be? Are the Google roots and/or the GlobalSign-acquired roots currently issuing EE certificates? Were they issuing certificates between 11th August 2016 and 8th December 2016? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 13/02/17 14:34, Doug Beattie wrote: > This was for GlobalSign account used for testing, so it was a > GlobalSIgn employee. Customers are not, nor have they ever been, > permitted to add domains without GlobalSign enforcing the domain > verification process. But currently GlobalSign employees still are? If so, can you help us understand why that's necessary? Given that you control the domains used for testing, you should be able to set them up to auto-pass some form of automated validation, so imposing a validation requirement for every addition would not, at least on a superficial understanding, lead to increased friction in testing. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediates Supporting Many EE Certs
On 13/02/17 19:22, Jeremy Rowley wrote: > As we tied the intermediate to a specific set of companies (which correlated > roughly to a specific volume of certificates), renewal and pinning were > non-issues. As long as each company was identified under the same umbrella, > an entity renewing, ordering a new cert, or pinning received the same > intermediate each time and was tied to the specific entity. This seems like a sane idea. Any CA which was required to rotate its intermediates would not be required to rotate them on a time basis; they could choose any rotation scheme they liked which kept them within the per-intermediate limits. _However_, if multiple intermediates are being issued under at once, and there is a process or other problem, the likelihood of them all being affected is high. (The rest of the validation path would likely be the same.) Therefore, you haven't necessarily solved the problem. Can a more complex rotation scheme square this circle? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediates Supporting Many EE Certs
On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote: > Isn't this mostly something that CAs should keep in mind when they > setup "shop"? > > I mean it would be nice to have a way of avoiding that kind of impact > of course, but if they think it's best to put all their eggs in one > basket... ;-) Well, if it's harder for us to dis-trust an intermediate with many leafs due to the site impact, the CA may decide to do it that way precisely because it is harder! Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 23:13, Santhan Raj wrote: > One thing to highlight here is that the WebTrust audits are performed > against the BRs and not against the root program requirements. This is true, although (apart from the relative importance of domain validation) this is similarly true of many items in the Mozilla requirements which we cannot directly check. > So hopefully > 169 makes it's way to BR soon. I am hopeful that most or all of the methods will be back in the BRs soon. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediates Supporting Many EE Certs
On 13/02/17 16:17, Steve Medin wrote: > Getting all user agents with interest is issuance limits to implement > the CA Issuers form of AIA for dynamic path discovery and educating > server operators to get out of the practice of static chain > installation on servers would make CA rollovers fairly fluid and less > subject to operator error of failing to install the proper > intermediate. Regardless of the merits of this proposal, this is: https://bugzilla.mozilla.org/show_bug.cgi?id=399324 which was reported 10 years ago, and resolved WONTFIX a year ago. It seems unlikely that this decision will be reversed, it will be implemented in Firefox and Chrome for Android, and then become ubiquitous, any time soon. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
GoDaddy Misissuance Action Items
As members of the group will be aware, last month GoDaddy filed an incident report concerning a problem with their domain validation system. Domain validation is the most important task a CA can undertake, any any flaws in it are serious. This is why the CAB Forum has been working for some time on carefully documenting best practice in domain validation, and passed ballot 169 to incorporate them into the Baseline Requirements. The problem experienced by GoDaddy is one explicitly foreseen by the drafters of those best-practice validation methods. That is why, despite some IPR-related tangles, Mozilla will be requiring in its next CA Communication that all CAs move to using only those documented methods in a fairly short timeframe, regardless of what the BRs say. CAs may wish to not wait for that communication to arrive before starting to adapt their systems. We note that GoDaddy's response to this issue was delayed because it was not submitted through their expected channels. We will be working in the CAB Forum to get the CAB Forum to host a master list of CA security contacts, open both to CAs who are and are not members of the Forum, to try and reduce the likelihood of this happening in future. We asked GoDaddy for a list of domains where they revoked the cert because they could not re-do the validation, and compared them to the Alexa top 1M domains. There were no hits in the top 10,000, and only 15 in the top 100,000. As attackers tend to target popular domains, we feel it is _unlikely_ that any certs ended up in the wrong hands as a result of this problem. So we do not plan to add any of the 8951 certs to OneCRL. Here is our proposed remediation plan for GoDaddy. 1) As with all CAs, update all their domain validation code to use one of the 10 approved methods; 2) Implement comprehensive automated testing for their domain validation code for all issuance systems; 3) Make sure those tests automatically run when any change is made to the code, before deployment, such that deployment is gated on a pass; 4) Get a statement from their auditors that these tests have been created and positioned correctly in the deployment workflow. All steps to be completed within 3 months. Comments on this plan are welcome, including from GoDaddy. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Intermediates Supporting Many EE Certs
The GoDaddy situation raises an additional issue. Mozilla is neither adding any of the 8951 revoked certificates to OneCRL, nor untrusting any GoDaddy intermediates. However, a more serious incident might have led us to consider that course of action. In that regard, the following information is worth considering. The certificates in the GoDaddy case chain up to two different intermediates: GoDaddy Secure Certificate Authority - G2 : 6563 Starfield Secure Certificate Authority - G2 : 2388 Those two intermediates together support over a million certificates, with a roughly 90/10 split between GoDaddy and Starfield. GoDaddy does not have a rotation policy for intermediates. Un-trusting such intermediates from the current date onwards is possible; un-trusting them from a date in the past would be extremely impactful to sites. Using this particular problem as an example, it occurred between July 2016 and January 2017. If we wanted to untrust these intermediates from July 2016 onwards, that would affect (by my rough guess) around 300,000 certificates. (The actual figure will depend upon the lifetime distribution histogram.) Contacting that many customers and getting them to rotate their certs would be a gargantuan effort. What can be done about the potential future issue (which might happen with any large CA) of the need to untrust a popular intermediate? Suggestions welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, On 12/02/17 15:27, Steve Medin wrote: > A response is now available in Bugzilla 1334377 and directly at: > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thank you for this timely response. Mozilla continues to expect answers to all reasonable and polite questions posed in our forum, and is happy that Symantec is taking this approach. Here are some additional questions, although Mozilla as always reserves the right to ask more later. Some of my questions may be similar to those posed by other group participants. * What criteria are Symantec using to judge whether the validation of a particular certificate was deficient and needs redoing? Does this process rely on an assumption that any work logs kept by the RAs are accurate records of work actually done? * When you say "Symantec authorized CrossCert to issue certificates from each of the identified CAs", do you mean all five separate certificates listed to the left of this answer in the document? Or do you mean the top list? Or the bottom list? Or something else? * When the revalidation process is complete, will Symantec be reporting on how many certificates were unable to be revalidated? * Further to your third response, can you provide a list of the certificate fields which CrossCert did or did not have control over, and whether those fields had Symantec-side validation with compliance flagging, and whether those flags could be overridden? To show what I am after, such a list might hypothetically begin: - notBefore/notAfter: no direct control - Certificate duration: control, minimum 12 months, maximum 39 months - Hash algorithm: no control - Domain name: full control, Symantec-side validation, overrideable * You write: "Further, we have deployed support for, and honor Certification Authority Authorization across all systems to put control of authorized CA’s in the hands of customers". This is great news :-) From what date has this been true? Can you confirm that CAA checking applies to all Symantec-owned brands? * Further to your answer about sampling sizes, what (in Symantec's experience) normally defines the sample size an auditor will use when sampling issued certificates during an audit? Is it a fixed number, or defined by the auditor, the issuer, or a dialogue between the two, or some other method? * http://vtn.certisign.com.br/repositorio/politicas/DPC_da_Cert isign.pdf is dated 2012. BRs section 2 say that the CP and CPS need to be annually updated. Do we understand that this did not happen in the case of Certisign? * Same question for CrossCert. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: (Possible) DigiCert EV Violation
On 27/02/17 21:41, Ryan Sleevi wrote: > During a past discussion of precertificates, at > https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ > , Mozilla did not discuss whether or not it considered > precertificates misissuance, although one module peer (hi! it's me!) > suggested they were. On this particular point, the CT RFC says that issuing a pre-certificate is a binding statement of intent to issue the certificate. Therefore, for example, one can exempt the cert itself from CAA checking if the pre-cert was checked. Therefore, I would say that we do consider mis-issued pre-certs as misissuance. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On 26/02/17 00:50, Itzhak Daniel wrote: > I talked with Ofer from Incapsula, he said the domain exist at some > point; Someone have access to domain tools or other tool to verify > this matter? Based on domaintools I can say the domain did exist but > I can't tell when it cease to exist. I think that without more evidence we must assume that GlobalSign validated this domain correctly at a time when it existed. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Ryan H, On 23/02/17 04:40, Peter Bowen wrote: > Both Gerv and I posted follow up questions almost two weeks ago. I > know you have been busy with CT days. When do you expect to have > answers available? Ping? :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
On 01/03/17 10:36, benjaminp...@gmail.com wrote: > screenshot of the error message: http://imgur.com/a/BIQUm That error message will not occur if only the root CA is SHA-1 signed, because Firefox does not check the signatures on root CAs. There must be some other certificate in the chain that Firefox has built which is SHA-1 signed. You will need to provide the full certificate chain as constructed by Firefox. If you get the error by visiting the site, then click "Advanced" then "Add Exception" then "View" then the "Details" tab, then select all the certificates in the chain in turn and click Export, making sure you save them as PEM files, you can paste them into a message to this group. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
Hi Doug, On 15/02/17 17:09, Gervase Markham wrote: > But currently GlobalSign employees still are? > > If so, can you help us understand why that's necessary? Given that you > control the domains used for testing, you should be able to set them up > to auto-pass some form of automated validation, so imposing a validation > requirement for every addition would not, at least on a superficial > understanding, lead to increased friction in testing. It's been quite some time since this question was posed; when might you have a response? Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 21/03/17 10:16, Gervase Markham wrote: > On 17/03/17 11:30, Gervase Markham wrote: >> The URL for the draft of the next CA Communication is here: >> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 > > A few more wording tweaks on the current version: In Action 1, we should replace: "However, if additional methods of domain validation are added to section 3.2.2.4 of the BRs in the future, they will also be permitted." with: "Mozilla expects that all missing methods will be restored to the Baseline Requirements in the near future. Once that happens, we will return to the practice of requiring conformance to the latest version of the BRs." (The CAB Forum PAG is about to resolve itself; happily, all participants have agreed to license their patents under a CAB Forum RF license. It's now just a question of getting a ballot done to add back the missing methods. Yay :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates
On 23/03/17 19:54, Jakob Bohm wrote: > The above message (and one by Symantec) were posted to the > mozilla.dev.security.policy newsgroup prior to becoming aware of > Google's decision to move the discussion to its own private mailing > list and procedures. I would encourage everyone concerned to keep the > public Mozilla newsgroup copied on all messages in this discussion, > which seems to have extremely wide repercussions. Actually, could I encourage everyone _not_ to do that? Ryan has requested this discussion happen on the blink-dev list. Not everyone who is a member here is a member there, or vice versa, and attempting to have the discussion across both lists is likely to lead to significant fragmentation and confusion. Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 07/03/17 11:37, Gervase Markham wrote: > Here are some proposals for policy change. Please do comment on these or > suggest others. I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this week, there was broad consensus to draw up a ballot which prevents CAs from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain name and IP address ownership - validation to third parties, and that this restriction would be enacted at the level of the BRs, not the level of Mozilla policy. So I will be working with interested parties from the Forum to draft some wording that achieves that, as there are various cases to consider to make sure we don't forbid certain common and secure activities by accident. This would be stronger than and therefore supercede: > Policy Proposal 1: require all CAs to arrange it so that certs validated > by an RA are issued from one or more intermediates dedicated solely to > that RA, with such intermediates clearly labelled with the name of the > RA in the Subject. Other forms of validation will continue to be outsourceable. Mozilla does not recognise OV certificates, but when it comes to EV, we do need to make sure that any outsourcing is properly audited and those audit findings are properly communicated. How we do this remains an open and difficult question; however, domain/IP ownership validation is so core to a CA's activity that it seems wise to remove it from the scope of this wider problem by banning outsourcing it outright. I will take up the topic of possible action against Symantec in the other thread. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 17/03/17 16:28, douglas.beat...@gmail.com wrote:
>> If the addition is so gated, what did the employee in this case do? Did
>> they upload bogus data?
>
> No bogus data was uploaded.
I spoke about this with Doug at the CAB Forum meeting. The system which
collects the data is not integrated with the system to which the domains
are added. The validation specialist concerned, contrary to policy
("it's just a test"), simply did not add any data to the data recording
system relating to the addition of this domain to the authorized list
for the account.
This raises the question of whether Mozilla should attempt to require
such linkage by policy, so that domains cannot be added unless domain
validation has been performed. It would not be a totally unprecendented
mandate (at the moment we e.g. require 2-factor auth, which is a direct
mandate for how CA systems operate). However, not all methods of domain
validation are automated. Given that if someone wants to work around the
system, it's not really possible to programmatically check that e.g.
someone's write-up of a phone conversation is genuine or not, I am
minded not to attempt this.
Comments?
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 23/03/17 23:07, Kathleen Wilson wrote: > Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of > the BRs does not contain all 10 of these methods, but it does contain > section 3.2.2.4.11, "Other Methods", so the subsections of version > 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are > still BR-compliant under version 1.4.2. By Mozilla policy, CAs are > not permitted to rely on the "Other Methods" section to use methods > of domain validation that are not among the 10 listed in section > 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the > methods for doing domain validation that are missing in version 1.4.2 > of the BRs will be restored to a forthcoming version of the BRs, so > we will once again be able to accept all of the methods of domain > validation listed in the latest version of the BRs. ~~ That's not quite it, because the first bit is still confusing (my fault), and the last para suggests we currently don't accept all methods listed, which we do. Can we try the following? Note that version 1.4.2 of the BRs does not contain all 10 of these methods, but it does contain section 3.2.2.4.11, "Other Methods", so the methods that were removed in version 1.4.2 of the BRs are still BR-compliant under that version. By Mozilla policy, CAs are not permitted to rely on the "Other Methods" section to use methods of domain validation that are not among the 10 listed in section 3.2.2.4 of version 1.4.1 of the BRs. As the IPR issues relating to these missing methods have now been resolved, Mozilla expects that they will soon be restored. Once they are, our policy will once again become that "we accept all of the methods of domain validation explicitly listed in the latest version of the BRs". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google action related to Symantec
On 23/03/17 16:09, Ryan Sleevi wrote: > You can participate in this discussion at > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs Participants who want to discuss Google's action should, of course, visit the Blink forum above as Ryan has requested. However, the discussion about what action Mozilla should take regarding Symantec remains open. (My apologies for not driving it forward; it was CAB Forum this week.) Here are some additional thoughts I have on this topic, but I have not yet reached a conclusion to recommend to Kathleen. The root stores tend to actively avoid coordinating enforcement actions ahead of any public announcement, to avoid accusations of impropriety. But now that Google have announced their action, it is unavoidable to note that it can be preferable for two root stores considering action against a CA to take broadly parallel approaches, so that the CA is not doubly penalised for the same actions. Google's communication has two parts (which are intermingled in the message as written) - a summary of Symantec's issues as they see them, and then a plan of action for changes they want to make in response to those issues. As far as the summary of issues goes, my understanding of the situation is broadly the same - that is, Google has correctly identified the things that have gone wrong, and appropriately assessed the severity of the problems. It is particularly concerning to me that Symantec discovered that one of their RAs was doing a terrible job and, while they demanded remediation, did nothing about existing certificates issued by that RA. An additional consideration in deciding on what action to take is whether a particular incident fits into a pattern for a particular CA. In the case of WoSign, while there were one or two unusually bad things about what they did, once we started investigating it became clear that these fit into a persistent pattern of ongoing problems. In the case of Symantec, it is borderline whether that test has been met. It is true that this incident and the previous "test cert" one are both serious, and both involved test certs - although this most recent one then turned up other problems. And they also have, like several CAs, managed to issue some unpermitted SHA-1 in 2016 despite attempting to update their systems to stop it. But we have not seen the sheer number of different problems that we saw with WoSign. Considering all that, calibrating a level of response is a difficult question. It is important to be consistent with previous precedent (with some consideration given to the fact that a second or third CA to take some bad action should have taken warning from the fate of the first) but there are few enough precedents in this area that any choice of level of action will always be open to both "you should do more" and "you should do less" criticism. Google's plan is, in my personal opinion, at the "strong" end of the options I was considering. Google's gradated distrust plan aims to minimise or spread the compatibility risk. Emulating it exactly would be difficult in any case, due to the fact that our releases do not line up with theirs. However, a simpler version may have the same effect in practice, given Chrome's ability to drive the market alone. Further comments and thoughts on the above are welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote: > Will that remain the responsibility of GlobalSign for any existing > certificates that have been signed with these roots? (Those would be > intermediate certificates, if I understand correctly.) Or does > revocation also require signing, and does it therefore become the > responsibility of the new owner of the roots? The latter - Mozilla would hold Google ultimately responsible for any revocation-related requirements in these hierarchies. (They may, of course, contract GlobalSign to manage some subset of it, but that's not our business). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Grace Period for Sub-CA Disclosure
On 27/03/17 23:12, Andrew Ayer wrote: > My interpretation of the policy is that a CA could delay disclosure for > quite some time if the sub-CA is not used to issue certificates right > away. If the sub-CA is created as a backup that is never used, the > disclosure would never need to happen. > > I think this is bad. Your case is missing the part where you explain why you think this is bad :-) What risks are associated with undisclosed dormant sub-CA certs? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 27/03/17 16:22, Ryan Sleevi wrote: > Would it be useful to thus also query whether there would be impact in > Mozilla applications failing to trust such certificates, but otherwise to > continue permitting their issuance. That is a good idea. How about: If you are unable to support a comprehensive reduction in issuance lifetime, please explain the impact you see of Mozilla (and potentially other browsers) removing trust from certificates of lifetime > 13 months in the same sort of timeframe. This would mean browser-facing certificates would need to have shorter lifetimes, but those certificates not issued for trust by browsers could have longer lifetimes. > That is a separate, but related, question, but useful to consider if you > will be asking all CAs, some of whom may have reasons due to other PKIs > that would make them concerned about potential impact. However, if > Mozilla's goals and desires would include seeing those PKIs are operated > independently of the Web PKI, then forbidding issuance would be appropriate. Presumably you mean independently apart from the fact that they happen to share roots? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites
On 27/03/17 23:15, mono.r...@gmail.com wrote: > Are there general proposals yet on how to distinguish phishing vs > legitimate when it comes to domains? (like apple.com vs app1e.com vs > mom'n'pop farmer's myapple.com) Not for those sorts of differences. There are in an IDN context: http://unicode.org/reports/tr39/ Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites
On 27/03/17 16:08, Martin Heaps wrote: > The next level is now that any business or high valued entity should > over the course of the next few years implement EV certificates (many > already have) and that browsers should make EV certificates MORE > noticable on websites.. or we should decide that the phishing problem is not best solved at the level of certificates, but instead at a higher level (e.g. Safe Browsing and similar mechanisms). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 17/03/17 15:30, Gervase Markham wrote: > The URL for the draft of the next CA Communication is here: > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 > > Note that this is a _draft_ - the form parts will not work, and no CA > should attempt to use this URL or the form to send in any responses. Here is another proposed question: Certificate Validity Periods Your attention is drawn to CAB Forum ballot 193, which recently passed. This reduces the maximum permissible lifetime of certificates from 39 to 27 months, as of 1st March 2018. In addition, it reduces the amount of time validation information can be reused, from 39 to 27 months, as of 31st March 2017. Please be aware of these deadlines so you can adjust your practices accordingly. Mozilla is interested in, and the CAB Forum continues to discuss, the possibility of further reductions in certificate lifetime. We see a benefit here in reducing the overall turnover time it takes for an improvement in practices or algorithms to make its way through the entire WebPKI. Shorter times, carefully managed, also encourage the ecosystem towards automation, which is beneficial when quick changes need to be made in response to security incidents. Specifically, Mozilla is currently considering a reduction to 13 months, effective as of 1st March 2019 (2 years from now). Alternatively, several CAs have said that the need for contract renegotiation is a significant issue when reducing lifetimes, so in order that CAs will only have to do this once rather than twice, another option would be to require the reduction from 1st March 2018 (1 year from now), the current reduction date. Please explain whether you would support such a further reduction dated to one or both of those dates and, if not, what specifically prevents you from lending your support to such a move. You may wish to reference the discussion on the CAB Forum public mailing list to familiarise yourself with the detailed arguments in favour of certificate lifetime reduction. Comments, as always, are welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Grace Period for Sub-CA Disclosure
On 28/03/17 12:21, Rob Stradling wrote: > Increased attack surface. An undisclosed dormant sub-CA most likely has > its private key in an online HSM, and so I think it's prudent to assume > that it's more vulnerable (to being compromised by an attacker, or to > being accidentally used to misissue a cert) than an offline root key. If it's dormant, there's no particular reason the HSM will be online. But it might be, and it doesn't make much sense to make a distinction in the policy. > IINM, the purpose (so far) of Mozilla's intermediate cert disclosure > policy is to map the attack surface. Right? That's certainly one goal :-) Does a week sound about right? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 15:35, Peter Kurrasch wrote: > In other words, what used to be a trust anchor is now no better at > establishing trust than the end-entity cert one is trying to validate or > investigate (for example, in a forensic context) in the first place. I > hardly think this redefinition of trust anchor improves the state of the > global PKI and I sincerely hope it does not become a trend. The trouble is, you want to optimise the system for people who make individual personal trust decisions about individual roots. We would like to optimise it for ubiquitous minimum-DV encryption, which requires mechanisms permitting new market entrants on a timescale less than 5+ years. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 20:42, Jakob Bohm wrote: > That goal would be equally (in fact better) served by new market > entrants getting cross-signed by incumbents, like Let's encrypt did. Google will be issuing from Google-branded intermediates under the ex-GlobalSign roots. So the chains would be basically the same whether GS or GTS owned the parent root. So how does requiring them to do it by cross-signing improve things? Requiring them to do it by cross-signing just exposes them to business risk which they don't have if they actually own the roots. > For example, when doing ordinary browsing with https on-by-default, > users rarely bother checking the certificate beyond "the browser says > it is not a MitM attack, good". Except when visiting a high value > site, such as a government site to file a change in ownership of an > entire house (such sites DO exist). Then it makes sense to click on > the certificate user interface and check that the supposed "Government > Land Ownership Registry of the Kingdom of X" site is verified by > someone that could reasonably be trusted to do so (i.e. not a national > CA of the republic of Y or the semi-internal CA of some private > megacorp). This is what we have CAA and HPKP for. > With this recent transaction, the browser could show "GlobalSign" when > it should show "Google", two companies with very different security and > privacy reputations. If Google were issuing from a Google-owned intermediate under a GlobalSign-owned root, why would the browser show "Google"? I don't understand how you see the chain differing in this situation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 31/03/17 17:39, Peter Bowen wrote: >>> For example, how frequently should roots >>> be allowed to change hands? What would Mozilla's response be if >>> GalaxyTrust (an operator not in the program) >>> were to say that they are acquiring the HARICA root? >> >> From the above URL: "In addition, if the receiving company is new to the >> Mozilla root program, there must also be a public discussion regarding >> their admittance to the root program." >> >> Without completing the necessary steps, GalaxyTrust would not be admitted to >> the root program. > > I've modified the quoted text a little to try to make this example > clearer, as I think the prior example conflated multiple things and > used language that did not help clarify the situation. > > Is the revised example accurate? The revised example is accurate. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Issues List
As we continue to consider how best to react to the most recent incident involving Symantec, and given that there is a question of whether it is part of a pattern of behaviour, it seemed best to produce an issues list as we did with WoSign. This means Symantec has proper opportunity to respond to issues raised and those responses can be documented in one place and the clearest overayll picture can be seen by the community. So I have prepared: https://wiki.mozilla.org/CA:Symantec_Issues I will now be dropping Symantec an email asking them to begin the process of providing whatever comment, factual correction or input they feel appropriate. If anyone in this group feels they have an issue which it is appropriate to add to the list, please send me email with the details. Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Root Store Policy 2.4.1
On 06/03/17 15:10, Gervase Markham wrote: > The next stage in the improvement of the Mozilla Root Store Policy is > version 2.4.1. This is version 2.4, but rearranged significantly to have > a more topic-based ordering and structure to it. I have also made > editorial changes to clean up and clarify language, and improved the > Markdown markup. Thanks to Ryan for reviewing this, and I need to come back to his comments. If anyone else has time to look through it, I would be most grateful. CAs: this is worth your time, because you don't want a new normative requirement sprung on you accidentally! ;-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Next CA Communication
The URL for the draft of the next CA Communication is here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 Note that this is a _draft_ - the form parts will not work, and no CA should attempt to use this URL or the form to send in any responses. Please provide feedback in this group on whether the questions and actions are clear, whether they are appropriate, and whether anything else should or could be added. Some of these items are effectively new policy (such as the requirement to rev CP/CPS version numbers at least yearly); if they survive unscathed, we will update the policy doc to include them. We'd like to send out this Communication before the end of this month. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 16/03/17 11:25, douglas.beat...@gmail.com wrote: > For the record, we don't think it's necessary (or permissible) to > give employees (RAs) the power to add arbitrary domains to accounts > without proper vetting. I guess I'm still not being clear - sorry :-( Let me try one more time: Why does GlobalSign believe it is necessary for employees to have the technical capability to add arbitrary domains to accounts without going through ownership validation? I mean, clearly they did back in 2015, because that's exactly what happened. Do they still have the technical capability (ignoring policy and set procedures for a moment) or not? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 20/03/17 15:33, Kathleen Wilson wrote: >> * Action 7: some of the BR Compliance bugs relate to CAs which are no >> longer trusted, like StartCom. If StartCom does become a trusted CA >> again, it will be with new systems which most likely do not have the >> same bugs. Should we close the StartCom compliance bugs? > > Yes, I think that makes sense. OK, I've closed the StartCom and ANSSI bugs. >> * Action 8: Can we provide more structure here, by perhaps putting some >> boilerplate text in the answer box or something like that? Or at least >> list the sections and actions we expect to have been done? > > Changed to checkboxes and a follow-up text field. Please review. You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to our root certificates included in Mozilla’s CA Certificate Program have either expired or been revoked." I don't think we _required_ revocation of all publicly-trusted SHA-1 certs, did we? Also, the two about "all... certificates" might need to be changed to "Our policy now is that all... certificates". >> C) CAA > > Added, but please carefully review -- not sure I got it correct. Looks good to me. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 20/03/17 13:07, Peter Bowen wrote: >> E) SHA-1 and S/MIME >> >> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your >> plans for ceasing to do so, and any self-imposed or external deadlines >> you are planning to meet. Mozilla plans to make policy in this area in >> the future, so please explain any facts or constraints which you think >> might be relevant to our considerations. > > Why is this limited to s/mime? It would be highly valuable to > understand if any SHA-1 signatures are being created using keys > trusted to sign server auth certs. Presumably you mean outside the scope of the BRs? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 17/03/17 15:30, Gervase Markham wrote: > The URL for the draft of the next CA Communication is here: > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 * Action 1 should say that if in future additional specific methods are defined by the CAB Forum, then they will be permitted also. * Clarifying: "so the subsections of version 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant" -> "so the subsections of section 3.2.2.4 in 1.4.1 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant under 1.4.2". * Action 1: Kathleen, I believe you said that 1/1/2016 is the earliest date the widget will do, but the text asks for 1/1/2015 (if you don't have the Websites trust bit)? * Action 2: as the two choices are mutually exclusive, I would expect radio buttons rather than a checkbox. * Action 3: "in github" -> "on Github". * Action 5: policy 2.4 has some of these requirements but not all. I've filed an issue to add any extra ones. https://github.com/mozilla/pkipolicy/issues/66 * Action 7: some of the BR Compliance bugs relate to CAs which are no longer trusted, like StartCom. If StartCom does become a trusted CA again, it will be with new systems which most likely do not have the same bugs. Should we close the StartCom compliance bugs? * Action 7: I have updated these bugs to have a convention of putting the CA name at the start of the bug summary. This allows sorting "by CA" if you sort by Summary. * Action 8: Can we provide more structure here, by perhaps putting some boilerplate text in the answer box or something like that? Or at least list the sections and actions we expect to have been done? I would also like to add the following questions/actions: A) Does your CA have an RA program, whereby non-Affiliates of your company perform aspects of certificate validation on your behalf under contract? If so, please tell us about the program, including: * How many companies are involved * Which of those companies do their own domain ownership validation * What measures you have in place to ensure this work is done to an appropriate standard If you do not have an RA program, write "Not Applicable". B) Your attention is drawn to the cablint and x509lint tools, which you may wish to incorporate into your certificate issuance pipeline to get early warning of circumstances when you are issuing certificates which do not meet the Baseline Requirements (cablint) or X509 standards (x509lint). https://github.com/kroeckx/x509lint XXX What's the URL for cablint? [ ] I am now aware of these tools C) CAA The CAB Forum recently passed ballot 187, which updated the Baseline Requirements to make CAA (RFC 6844) checking mandatory at time of certificate issuance in almost all circumstances. Please provide a list of the domain names which your CA plans to recognise in a CAA record's issue and issuewild property tags as permitting it to issue. If certain identifiers only permit under certain circumstances, please explain. Mozilla plans to make a central list of these identifiers. D) Problem Reporting Mechanism Please explain how your CA meets the following requirement from the BRs section 4.9.3: “The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Please detail both the mechanism and the location(s) where you publicly disclose it. Mozilla plans to make a central list of these mechanisms. You are encouraged to make an email address at least one of your provided options. E) SHA-1 and S/MIME Does your CA issue SHA-1 S/MIME certificates? If so, please explain your plans for ceasing to do so, and any self-imposed or external deadlines you are planning to meet. Mozilla plans to make policy in this area in the future, so please explain any facts or constraints which you think might be relevant to our considerations. If none of your roots have the Email trust bit set, write "Not Applicable". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 16/03/17 13:15, Ryan Sleevi wrote: > Or, put differently, it sounds as if you suggest the only obligation a CA > has to ensure their DTP auditors are qualified for the task at hand is if, > and only if, Mozilla requests those audits. In the absence of that request, > the CA is allowed to make their own individual determination. Further, it > seems that you are suggesting that if a CA makes that determination, and > it's incorrect, that's not a failure upon the CAs part, because they made > 'a decision', and the relevant portions of Mozilla policy only apply to the > 'next' audit. I am saying that, however, undesirable, our current policy could be interpreted this way, which is why I want to change it. You don't have to convince me that this situation is undesirable :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 16/03/17 17:20, douglas.beat...@gmail.com wrote: > Yes, RAs (trusted role employees) need to have the technical ability > to manually add domains to accounts. They can verify domains in one > of the 10 different methods and some of those involve manually > looking in who-is for registrant info, using a DAD or in calling the > contact. When one of these is used, we collect the vetting data then > the RA can add/approve that domain. But is the addition of the domain gated on the uploading/attachment/submission of what could plausibly be vetting data? I mean, I understand you can't programmatically check that a person has made a phone call. But you can require them to write a report of the results of that phone call and not allow addition of the domain until they've done it. Yes, they could just put "flibbertigibbet" into the text box, but that at least shows they are deliberately bypassing the process. If the addition is so gated, what did the employee in this case do? Did they upload bogus data? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 17/03/17 11:30, Gervase Markham wrote: > The URL for the draft of the next CA Communication is here: > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 A few more wording tweaks on the current version: * Action 1 says: "Date must be before June 1, 2017". That gives CAs 2 months to make a CP/CPS update. Do we normally allow a bit more than that for non-urgent updates? Say, 3 months? * "I understand that our CP/CPS documents shall be updated each year" -> "I understand that our CP/CPS documents should be reviewed and the version number incremented each year" * Action 8: "Our current policy is...". In hindsight, this is ambiguous - it could be Mozilla's policy, and the CA is just affirming they understand it. Instead say "The current policy of our CA is...". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 07/03/17 10:18, Gervase Markham wrote: > OK. Question for group: would it make sense to add the intermediate(s) > that GlobalSign is using for this purpose directly to the Mozilla trust > store, with the EV bit enabled, and then remove the EV bit from the > roots now owned by Google Trust Services? > > This would scope EV permissions more closely to the audits, and so > prevent Google from accidentally or intentionally issuing EV which was > shown as such in Firefox, without having an EV audit. Hearing no dissent, filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 09/03/17 13:32, Ryan Sleevi wrote: > (Wearing Google hat only for this statement) > Have you considered having this discussion in the CA/Browser Forum? Google > had planned to discuss this very topic at our upcoming F2F about how to > address this, and would be very interested in collaborating with Mozilla on > this. I mentioned this recently to Kathleen at the WebTrust TF meetings, > but apologies for not mentioning to you as well. This sounds like a good idea. Do we want to get this added in an open slot? There may still be time. > I'm not sure that we can or should so easily dismiss this with a suggestion > that we're dancing on the head of a pin here. That's not quite what I'm saying; I'm saying that my position could be seen as that (making very fine distinctions), and it possibly is. > I don't understand why you > believe it's relevant the act of "Mozilla requiring disclosure of the > audits". Can you help me understand where, in the policy, that's required? I'm not sure where your text in quotes comes from, and nor can I work out the referent of "it", so I don't understand this question. > I agree that removing the conflicting definition of qualified auditor is > likely a suitable outcome, and a much welcome improvement, but I do think > we owe it to the community to provide a greater degree of clarity then > currently provided by this thread about the expectations related to such > audits, both to the qualifications and the independence aspects. Surely requiring the auditor to be qualified in all cases will provide that clarity? I've filed https://github.com/mozilla/pkipolicy/issues/63 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/17 15:06, Peter Bowen wrote: > By eliminating the DTP option, you will massively raise costs for CAs > that rely upon local translators and information gatherers. I think a > much better proposal would be to require the CA perform the RA > activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to > Subject Identity Information validation. Let's call that "Policy Proposal 5" :-) I think that if we did this, it might still make sense to enact Policy Proposal 1. I believe that would have the side effect of making sure we get all the audits. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/17 16:20, Gervase Markham wrote: > On 09/02/17 22:55, Peter Bowen wrote: >> Policy Suggestion A) When transferring a root that is EV enabled, it >> should be clearly stated whether the recipient of the root is also >> receiving the EV policy OID(s). > > I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy Now done: "When transferring ownership of a root that is EV-enabled, it should be clearly stated whether the recipient of the root is also receiving the (right to use the) EV policy OID(s) and, if so, it should be confirmed that they have or will get the relevant audits before issuing EV certs." > Again, would this be covered by a requirement that no issuance was > permitted from a transferred root until all the paperwork was in place, > including appropriately-scoped audits? This might lead to a PITRA, but > would not have to. Now done: "No issuance whatsoever is permitted from a root certificate which has changed ownership by being sold by one company to another (as opposed to by acquisition of the owning company) until the receiving company has demonstrated to Mozilla that they have all the appropriate audits, CP/CPS documents and other systems in place. In addition, if the receiving company is new to the Mozilla root program, there must also be a public discussion regarding their admittance to the root program." https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
Hi Blake, On 02/03/17 16:26, blake.mor...@trustis.com wrote: > We have engaged with our external auditors in relation to this and the > previous certificate that was reported. Once that activity has concluded we > will be providing further information. Do you have an ETA for this incident report? It's been quite some time now. I am still interested to understand how a "full investigation" of the first certificate failed to turn up the second. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert BR violation
On 13/03/17 21:31, Jeremy Rowley wrote: > [JR] If you recall, I did try to change the policy. I was told to > change the RFC if I didn’t like the requirement. I find trying to > change the RFC nearly impossible as PKIX is dead and there are too > many other issues people would also like to change. If RFCs are unchangeably wrong, we should override them in the BRs. [citation needed] for the discussion where you were told to change the RFC; I'd like to read how that conversation went. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 16/03/17 10:50, Gervase Markham wrote: > https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership With these changes and the filing of https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this particular discussion RESOLVED. This means Mozilla plans to take no action against GTS based on what has been discovered and discussed. It doesn't mean people can't continue to make suggestions about improvements to our process, citing this situation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On 03/03/17 20:59, douglas.beat...@gmail.com wrote: > In general, when we receive new orders and issue certificates, the > vetting is done just prior to issuance time which permits the > certificate to be replaced up until expiration. We're looking into > cases where new "orders" may have used certificate data that was done > prior and then verifying that the domains (and enterprise data on the > subject DN) are re-verified at the applicable intervals. > > I'll send out an update as soon I have more information. Hi Doug, Any update? Once you report back, if nothing terrible is found, I think we can consider this matter resolved. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
On 28/02/17 20:02, douglas.beat...@gmail.com wrote: > And lastly this ticket. The Domain name was validated in accordance > with the BRs, but there was a bug that allowed a user entered space > to be included in some of the SAN values. While the value is not > compliant with RFC 5280 or the BRs, there was no security issue with > the certificate that was issued (it was likely not able to secure the > intended subdomains). We'll provide an incident report for this. Hi Doug, Any news on when we might see this incident report? Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
Hi Doug, On 03/03/17 11:17, Gervase Markham wrote: > That's lovely, but it doesn't answer my question. Let me restate it: why > does GlobalSign believe it is necessary to give employees the power to > add arbitrary domains to accounts without going through ownership > validation? You are getting various pings from me this morning :-) This question is still outstanding, and has been for a month now. Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues List
On 03/04/17 02:37, Peter Bowen wrote: > I believe Issue L is incorrectly dated. Thank you for this; I have updated Issue L to hopefully be more accurate, but I intend to keep it as a separate issue. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues List
On 01/04/17 05:57, Peter Bowen wrote: > The GeoRoot program was very similar to that offered by many CAs a few > years ago. CyberTrust (then Verizon, now DigiCert) has the OmniRoot > program, Entrust has a root signing program[1], and GlobalSign Trusted > Root[2] are just a few examples. While this is true, it's not just about the existence of the legacy program with problems, but about how the situation is handled. Verizon were not able to bring their program into BR compliance; DigiCert bought it and worked closely with Mozilla to generate some breathing space for them to clean the system up. They posted public plans, kept us informed of the issues found and their plans for remediation, and completed the work pretty much on time. The Web PKI is a better place for it. This does not seem to be the approach taken by Symantec, if we accept Ryan's account of events. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues List
On 01/04/17 00:38, Ryan Sleevi wrote: > On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy < > Thanks for organizing this information, as much of it was related to and > relevant to Google's recent announcement. I want to take this opportunity > to share additional details regarding the interactions for UniCredit, which > I believe may be useful and relevant both for understanding that issue and > the GeoTrust audits. Thank you for this. I will attempt to integrate it into the document and I'm sure we will hear comments from Symantec on it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response T
On 11/04/17 17:18, Ryan Sleevi wrote: > 1) On the basis of the controls Symantec described, at no point was any > mention made of Symantec performing sampling audits to ensure their RA > partners complied with either the RA partner's CP/CPS or Symantec's CP/CPS. > a) Is it fair to conclude that no such examination if done? In various rounds of questioning at the time we were focussing purely on this incident, I asked Symantec what processes they had in place for checking that the RAs were doing what they should. Their answer was "WebTrust audits". So I believe they have already said that no such examination was done. I'm sure they'd be happy to clarify, though. Most of your other questions are fairly stated (if perhaps rather broad in scope - are you expecting a total dump of all their internal procedure documents?). But particularly: > d) Is it fair to conclude that Symantec's belief is that it does not have > to follow the Baseline Requirements that it disagrees with? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues doc updated
On 11/04/17 17:34, Ryan Sleevi wrote: > Can you clarify what issues you believe this to be related? That is a fair question. And also hard work to answer :-) > Given that Symantec has a routine habit of exceeding any reasonable > deadline for response, at what point do you believe it is appropriate for > the Mozilla Root Store to begin discussing what steps can or should be > taken with respect to the documented and supported incidents, which > Symantec has not provided counter-factual data? Yes, fair enough. Rick and Steve: I will be taking Symantec's statements to this group as of one week from today as the sum total of what you have to say on the subjects under discussion. After that point, we will draw conclusions based on the available data and decide on what course of action we may take. I hope that by then you will be able to answer my 8 questions, and provide responses or comments to any of Ryan's or other people's questions that you wish to address. Kathleen is on vacation this week, and so no decisions could be taken until next week at the earliest anyway. > It's unclear from your remark "Started to draw some conclusions where that > is warranted" what you see as the process and next steps. Perhaps you could > clarify what you imagine happening next, and on what timeline, to provide > clarity both to Symantec and the general population here. I must admit, I'm > quite confused as to where things stand, given that many items have > conclusions to them. See above. After one week, I will be taking stock of the assembled evidence, and will invite community members also to draw conclusions. I will then present a recommendation for what we should do next. As you know, Mozilla's process is a little fuzzy around the edges, but Kathleen is the final decision maker. (And she doesn't always agree with me :-) > With respect to the conclusion to Issue T "Symantec's reaction to the > discovery of these problems was unarguably swift and comprehensive.", I > would disagree with this. Symantec's response was not swift, relative to > other CAs that have been informed of issues. It was not comprehensive - > Symantec failed to identify the issues until question, and still maintains, > in the latest response, that there is a conclusion unsupported by the > evidence they have shared with the community. Their timeline for > responsiveness was not swift - we're still discussing this specific issue, > and it was first reported on Issue T. I would be happy to find evidence of > issues from other CAs that demonstrate a more thorough response or a more > timely response. Within a few days of discovering these issues they shut down their entire RA program. That seems pretty swift and comprehensive to me. The fact that they didn't discover these issues for years is clearly a problem, but it's not the same problem. > With respect to the conclusion to Issue T, "Their case is that WebTrust > audit monitoring should have been sufficient," it's unclear if you are > agreeing with that conclusion or simply stating Symantec claims. Stating Symantec's claims. > With respect to the conclusion to Issue V, That's not part of my conclusion, that's a quotation from Symantec which I need to check the accuracy of with Kathleen. > "to specifically address the > GeoRoot audit status and remediation plan" - this was not reflected within > https://www.symantec.com/content/en/us/about/media/repository/23_Symantec_GeoTrust_WTBR_period_end_11-30-2016.pdf > , the relevant audit for the roots, ending on 2016-11-30. I'm a little confused - I think Symantec are saying that the cover letter explains the plan to wind down the two sub-CAs, not that the audit does? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response X
On 11/04/17 16:23, Ryan Sleevi wrote: > The audits mention the CP/CPS has been evaluated as part of the scope of > the audit. Yep, OK. > The CP/CPS mentions the issuance of TLS certificates as part of the > hierarchy. For example, > > "E-Sign provides its services in accordance with its Certificate Policy and > Certification Practices Statement" E-Sign's CPS URL is given in its audit statement as: https://www.e-sign.cl/uploads/cps_esign_388.pdf Grepping that document for "TLS" gives no hits. Can you help me some more? E-sign appear to be a Symantec SSL reseller: https://www.e-sign.cl/soluciones/seguridad but of course, I'm sure many companies are, and that's not necessarily a problem. MSC Trustgate's audit statement gives no CPS URL. https://cert.webtrust.org/SealFile?seal=2127=pdf However, it certainly appears to be true that this company offers a "Managed PKI for SSL" product: https://www.msctrustgate.com/pdf/ManagedPKIforSSL_Agreement.pdf and that they offer "VeriSign Class 3 organizational SSL Certificate"s, and lets organizations apply for RA status within the Verisign Trust Network. The modification date of that document according to the webserver is 15th March 2012. https://www.msctrustgate.com/product/ssl_id.htm also shows this. They also have a Subscriber Agreement for SSL certificates: https://www.msctrustgate.com/pdf/Class%203%20Organizational%20Certificate%20latest%20pdf.pdf which are also "Symantec Class 3 organizational SSL Certificate"s. The "Buy", "Renew" etc. links on the front page of https://www.msctrustgate.com/ for SSL certs are all 404. According to archive.org, they may have been that way for some time. Odd... Steve? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response X
On 11/04/17 17:51, Ryan Sleevi wrote: > Also, search SSL. Not TLS :) Aha! > Further, its CPS states > > "MSC Trustgate.com is a “Processing Center,” as described in CP § > 1.1.2.1.2, which > means MSC Trustgate.com has established a secure facility housing, among > other > things, CA systems, including the cryptographic modules holding the private > keys > used for the issuance of Certificates. MSC Trustgate.com acts as a CA in > the STN and > performs all Certificate lifecycle services of issuing, managing, revoking, > and > renewing Certificates. " That seems pretty clear. Perhaps Steve will be able to comment. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 11/04/17 14:05, Peter Kurrasch wrote: > Is there room to expand Mozilla policy in regards to ownership issues? Subject to available time (which, as you might guess by the traffic in this group, there's not a lot of right now, given that this is not my only job) there's always room to reconsider policy. But what we need is a clearly-stated and compelling case that changing the way we think about these things would have significant and realisable benefits, and that any downsides are fairly enumerated and balanced against those gains. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Questions for Symantec
Hi Steve and Rick, You have told me that you are considering your response(s) to the Symantec issues list, which is fine. Based on the list and further discussions which have been happening in m.d.s.policy, and on your recent audit publication, I thought it would be helpful to give a few specific questions that we are seeking answers to. (This should in no way be seen as trying to limit what else Symantec may wish to say.) It would be most convenient if you were to post the answers as a reply message in m.d.s.policy. Q1) Symantec's audit for 2014-2015: https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf says on page 11: "We noted that audit reports were not obtained during the examination period for 2 of 5 external partner subordinate CAs signed by the GeoTrust Global CA and managed by contracted third parties as part of the GeoRoot service). In addition, the report obtained for 1 of 5 external partner subordinate CAs was not in accordance with permitted audit schemes. Furthermore, in lieu of third party audits completed by delegated third parties, no out-of-band mechanisms were used to confirm the authenticity of the certificate requests, or the information supporting the certificate and internal reviews were not performed by Symantec to determine third party compliance with baseline requirements. For the 2 external partners where reports were not obtained during the examination period, one external partner’s subordinate CA has since expired and Symantec subsequently received an audit report for the other. For the other external partner, Symantec reviewed the report obtained and requested that their next report be in accordance with permitted audit schemes." A) Can you please identify all of the companies referenced here, by putting names to each reference? B) When the second paragraph, beginning "Furthermore", refers to "delegated third parties", does it mean the same five subordinate CAs as the first paragraph, or does it refer to the RA program that you recently shut down? C) If it refers to the same subordinate CAs, can you explain how the RA audits for CrossCert, Certisign, Certsuperior, and Certisur featured in the 2014-2015 auditing process? Where they examined by KPMG? Q2) Please give the names of all companies who have been in your RA program recently enough that there still exist unexpired certificates which were issued by them, and their start and end dates in the program. Although we have had some of this information before, for completeness please provide links to all audits for each company. Q3) Please give the names of all companies who have been in your GeoRoot program recently enough that there still exist unexpired certificates which were issued by them, and their start and end dates in the program. Please provide links to all audits for each company. Q4) Are there any other programs Symantec runs or has run in the past five years, other than the recently-terminated RA program and the GeoRoot program, which puts either the power of domain ownership validation or the power of certificate issuance in the hands of an organization other than Symantec or its Affiliates? If so, please give details of the program, and lists of companies, dates and any applicable audits as outlined above. Q5) You have recently released your 2016 audits, split into two parts at June 16th (6.5 months into the 12-month period). The audits for the first six months contain almost all of the qualifications that the 2015 audits have. Please can you give exact or approximate dates for "start of issue", "discovery of issue" and "problem fixed/ceased" for each of the following issues which led to a qualification: A) Test certificates issued for domains Symantec did not own or control B) Failure to maintain physical security records for 7 years C) Unauthorized employees with access to certificate issuance capability D) Failure to review application and system logs E) Background checks not renewed for trusted personnel after 5 years Q6) The management assertions in the audits for neither the first-half nor the second-half of 2016 contain any qualification related to the audit status of either your GeoRoot or RA program partners. Does this indicate that Symantec felt that all partners in these programs were in good standing audit-wise during the period from December 1st 2015 to November 31st 2016? Q7) In your comments at the time on what is now labelled Issue D, the misissuance of test certificates, you wrote: "First, we continued to issue internal test certificates to unregistered domains after the April 2014 change in the Baseline Requirements that removed authorization to do so." By "the April 2014 change", do you mean by ballot 112? https://cabforum.org/2014/04/03/ballot-112-replace-definition-internal-server-name-internal-name/ If so, can you explain how you see this ballot as affecting the correctness or otherwise of issuing certificate for
Re: Grace Period for Sub-CA Disclosure
On 27/03/17 22:12, Andrew Ayer wrote: > [ Corresponding issue on GitHub: > https://github.com/mozilla/pkipolicy/issues/67 ] This has now been added to the policy 2.5 draft with a one-week deadline. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Root Store Policy 2.5 update
I've started the process of working on policy version 2.5 (does it ever end? :-). The first thing I did was check in a number of tweaks and wording changes which were in the April CA Communication, and therefore had already been discussed, or which seemed uncontroversial. They are those listed here as being checked in on April 4th (today): https://github.com/mozilla/pkipolicy/commits/master and the sum total of the difference is here: https://github.com/mozilla/pkipolicy/compare/2.4.1...master I've also triaged the remaining bugs and selected some to fix for 2.5. They are here: https://github.com/mozilla/pkipolicy/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.5 This is not an exhaustive list; this is all the fairly small and simple stuff which seems to have built up. It may be that when we do all that, we'll have enough for an update and we can do the big stuff in 2.6. Or it may be that we then move on to the big stuff without shipping. I'm not sure yet. As I did for 2.4, I expect to post potential changes for discussion weekly, in batches of around 3. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions for Symantec
On 03/04/17 13:11, Gervase Markham wrote: > Hi Steve and Rick, Q8) The accountant's letters for the 2015-2016 audits are dated February 28th 2017. The audits were supplied to Mozilla, and published, on the 1st of April 2017. Why the delay? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
On 04/04/17 16:31, douglas.beat...@gmail.com wrote: > Attachment was stripped, here it the content: Thanks Doug. Unless anyone sees something particularly problematic here, I think we can call this incident closed. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On 31/03/17 22:20, Kathleen Wilson wrote: > Please let me know asap if you see any problems, typos, etc. in this > version. Now that policy 2.4.1 has been published, we should update Action 3 to say the following at the top: Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been published. Differences between 2.4 and 2.3 (published Dec 2016), and between 2.4 and 2.2 (published July 2013) may be viewed on Github. Version 2.4.1 contains exactly the same normative requirements as version 2.4 but has been completely reorganized. Please review version 2.4.1 policy and confirm that your CA complies with it. And then change the "2.4" to "2.4 or 2.4.1" underneath the bullet points. Other than that, LGTM - ship it :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
Hi Daniel, We appreciate your additional input into determining the exact scope of this problem. On 31/03/17 19:37, Daniel Baxter (Aractus) wrote: > With all due respect this reply is the most ridiculous load of > nonsense I've ever read. However, please keep the tone civil. If it's nonsense, demonstrate why that's so rather than asserting it. > Yeah OK, I got a few things wrong on my blog post, I can fix that > shortly. We would appreciate it if you would let us know what the updates are. > Firstly you claim email accounts should be secure - um since WHEN? Regardless of the wisdom of this assertion, it is true that many CAs rely on the (relative) security of email when doing domain validation. Symantec is not alone in this respect. It's probably not productive to have an argument at this point over whether email-based domain validation is a good idea or not. > Next, you say that URLs in emails should be treated like a password. > Um - SINCE WHEN? And furthermore, if it should be treated as a > password, if that's your claim, WHY ARE THEY BEING SENT IN PLAINTEXT > IN THE EMAIL? You can't have it both ways - if you want customers to > treat that as they do a password, you need to treat it with the same > care, and put it behind an authentication. This leads to a chicken-and-egg problem. To use email for domain validation, you need to send something in the email which the domain owner does not already know, and then use that to validate that the person wanting the certificate is able to receive the email. It doesn't matter whether it's a token or the username and password to a web interface. > Again, stop passing the buck. You need to assume that not every email > account in the world is secure! Also, it's a breach of s.6.1.2: > > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf > > No party other than subscriber shall archive the private key. I.e. > it should be impossible to retrieve from an email in the first > place. Do you have evidence that private keys were retrievable? Can you provide steps to reproduce? > How does that matter? Chris was able to do it, and if he was able to > then your investigation should have uncovered the vulnerability. The It would be great if Chris were available to drop in and corroborate this. I may reach out to him. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 31/03/17 20:26, Peter Kurrasch wrote: > The revised example is not entirely what I had in mind (more on that > in a minute) but as written now is mostly OK by me. I do have a > question as to whether the public discussion as mentioned must take > place before the actual transfer? In other words, will Mozilla > require that whatever entity is trying to purchase the root must be > fully admitted into the root program before the transfer takes > place? No. As currently worded, it has to take place before issuance is permitted. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
Hi Doug, Kathleen is unavailable this week, so I'll try and answer. (This might have been better as a new top-level post, though...) On 11/04/17 21:14, Doug Beattie wrote: > This is my understanding: > > - Under policy 2.3 a CA that is technically > constrained with EKU set to only secure email but without name > constraints was considered out of scope of the Mozilla Policy. Which parts of policy 2.3 lead you to that conclusion? https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md 2.3 does not have an explicit scope statement, something we fixed in 2.4. Policy 2.3, Application section, bullet 9, defines rules for technically constrained certificates, including a section giving rules for certs issued by technically constrained email sub-CAs. How do you then see these as out of scope? > - Policy 2.4.1 adds a requirement that for the CA to be out of scope of > the Mozilla policy the CA needs to have name constraints if the CA is > capable of issuing secure email certificates. Which parts of policy 2.4.1 lead you to that conclusion? https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Section 1.1.2 of 2.4.1 says that sub-CAs are included in the overall scope statement. There are two ways to be exempted - not be capable of issuing email certificates, or be name-constrained. So I assume you are referring to 1.1.2, bullet 2. But this says that to be exempted, you need to be not issuing any form of rfc822Name - in other words, it's a way of turning off email entirely using a different technical mechanism. This bullet is not met if you have name constraints which restrict you to particular email domains. So I would say that an email-only sub-CA which is name-constrained to certain domains is currently still in scope. And, indeed, section 5.3.1 is the new analogue of the old Application section, bullet 9 mentioned above, and contains the same language governing certs issued by technically constrained email-only sub-CAs. Of course, this is all related to: https://github.com/mozilla/pkipolicy/issues/36 :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues doc updated
On 11/04/17 23:07, Jakob Bohm wrote: > Please consider the fact that this is Easter week, and most of the > industry, including many people (on both the Browser and Symantec sides > of the process) are likely to be unavailable for precisely this week of > the entire year. > > In general, sending deadline mails (by paper, e-mail, process server or > otherwise) to anyone during a public holiday demanding actions during > that holiday is considered morally deficient at a minimum. That seems hyperbolic. However, your point is well taken. I have emailed Symantec to put back the deadline to 23:59 UTC on Thu 20th April. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Require qualified auditors unless agreed in advance
Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion, might need to use unofficially-qualified auditors to keep cost down. This is no longer a live issue, and this exception/expansion causes confusion and means that we cannot unambiguously require that auditors be qualified. Therefore, I propose we switch our auditor requirements to requiring qualified auditors, and saying that exceptions can be applied for in writing to Mozilla in advance of the audit starting, in which case Mozilla will make its own determination as to the suitability of the suggested party or parties. Proposed changes: * Remove sections 3.2.1 and 3.2.2. * Change section 3.2 to say: In normal circumstances, Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2. If a CA wishes to use auditors who do not fit that definition, they MUST receive written permission from Mozilla to do so in advance of the start of the audit engagement. Mozilla will make its own determination as to the suitability of the suggested party or parties, at its sole discretion. * Change section 2.3, first bullet, to read: - Mozilla reserves the right to accept audits by auditors who do not meet the qualifications given in section 8.2 of the Baseline Requirements. This is: https://github.com/mozilla/pkipolicy/issues/63 --- This is a proposed update to Mozilla's root store policy for version 2.5. Please keep discussion in this group rather than on Github. Silence is consent. Policy 2.4.1 (current version): https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Update process: https://wiki.mozilla.org/CA:CertPolicyUpdates ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use." This is bogus. What it says here is something that you have to do for any email cert - it's not a technical constraint but a policy constraint, and it's basically the same as 2.2.2: "for a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;" Section 5.3.1 should define technical constraints on the intermediate appropriate for restricting email addresses to a whitelist of domains, just as the section for id-kp-serverAuth restricts to a whitelist of domains. We don't have any "Email BRs" to refer to, but I think we want something like this: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." This is: https://github.com/mozilla/pkipolicy/issues/69 --- This is a proposed update to Mozilla's root store policy for version 2.5. Please keep discussion in this group rather than on Github. Silence is consent. Policy 2.4.1 (current version): https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Update process: https://wiki.mozilla.org/CA:CertPolicyUpdates ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
There are some items that it would be very helpful for auditors to state
in their public-facing audit documentation so that we can be clear about
what was covered and what was not. The policy already has some
requirements here, in section 3.1.3, mostly relating to dates.
The proposal is to add the following bullets to section 3.1.3 ("Public
Audit Information"), perhaps reordering the list as appropriate:
* name of the company being audited
* name and address of the organization performing the audit
* DN and SHA1 or SHA256 fingerprint of each root and intermediate
certificate that was in scope
* audit criteria (with version number) that were used to audit each of
the certificates
* For ETSI, a statement that the audit was a full audit, and which parts
of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP,
EVCP+, Part1 (General Requirements), and/or Part 2 (Requirements for
trust service providers).
This is: https://github.com/mozilla/pkipolicy/issues/58 and
https://github.com/mozilla/pkipolicy/issues/28 .
---
This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.
Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
On 11/04/17 22:08, Eric Mill wrote: > I'll leave it to others to opine on the severity of the mistake and the > quality of the response, but I do want to at least properly communicate the > impact. Thank you. I have updated my write-up for Issue L. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
On 12/04/17 11:41, Kurt Roeckx wrote: > But I'm also wondering what you expect if it contains other EKUs like > client auth, code sign, unknown. Do we always consider them constraint? Formally, we don't care if they also have those EKUs, or whether the use of those EKUs is constrained, because our root program is not concerned with those uses of certificates. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance
On 12/04/17 11:37, Jakob Bohm wrote: > Does this (accidentally?) remove the ability of Mozilla to explicitly > distrust a specific formally qualified auditor, such as E HK? Good point. Not sure, but we should make that clear. Add to the end of that exception sentence ", or refuse audits from auditors who do." Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 06/04/17 03:24, Peter Kurrasch wrote: > things they like. It's a very lucrative business so when I see a root > cert coming up for sale it's a no-brainer for me to go out and purchase > it. Having access to a root will undoubtedly come in handy as I grow my > business. The previous owner of the root cert, certainly if they have other roots and even if they don't, has an obligation to notify us of the sale. Until they do, they remain responsible for it, and whatever Easy Pete does with it. So I expect us to find out about the sale. > Once I take possession of the root cert's private key and related > assets, what will limit the bad actions that I intend to take? If you start issuing certs without the relevant paperwork in place, you'll be out of the root programs in the next security update, and you'll have spent a lot of money on a worthless asset. > And it's true that I may be prohibited from issuing certs per Mozilla > policy, but that actually is a bit of a squishy statement. For example, > I'll still need to reissue certs to the existing customers as their > certs expire or if they need rekeying. Er, no. No issuance is permitted. If you need to issue immediately, then you need to make sure the paperwork is in place and Mozilla is happy before possession is transferred. Then you can have near-uninterrupted service. > Leaving behind this land of hypotheticals, it seems to me the policy as > written is weaker than it ought to be. My own opinion is that only a > member CA should be allowed to purchase a root cert (and assets), > regardless if it's only one cert or the whole company. As noted in previous emails, I see membership as a consequence of owning an included root, rather than a separate thing. Clearly there are grey areas on joining and leaving, but it doesn't make sense to me for a company to be a member of the program if they don't own a root. > If that's going > too far, I think details are needed for what "regular business > operations" are allowed during the period between acquisition of the > root and acceptance into the Mozilla root program. None. The root transfer policy is very clear: "No issuance whatsoever is permitted from a root certificate which has changed ownership by being sold by one company to another (as opposed to by acquisition of the owning company) until the receiving company has demonstrated to Mozilla that they have all the appropriate audits, CP/CPS documents and other systems in place. In addition, if the receiving company is new to the Mozilla root program, there must also be a public discussion regarding their admittance to the root program." https://wiki.mozilla.org/CA:RootTransferPolicy A wise company would do this all in advance of taking possession if they wanted to issue immediately upon acquisition. In the GS/GTS case, GS kept a sub-CA and kept issuing from it under their own paperwork for customer continuity, which was fine. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 06/04/17 18:42, Jakob Bohm wrote: > Here are some ideas for reasonable new/enhanced policies (rough > sketches to be discussed and honed before insertion into a future > Mozilla policy version): I'm not sure what's new or enhanced about them. Our current policies are not this prescriptive so CAs have more flexibility in how they go about things, but I believe they preserve the same security invariants. In general, I suggest that if others have policy problems they see, you let them draft the solutions? :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: > 1) You're arguing that "the issuance of this cert didn't impose risk on > anyone but this specific customer" > a) What factors lead you to that decision? Can you lay out for us a scenario where this issuance might impose risk on someone else? > 2) You've noted that you did not disclose it due to "contractual > obligations to protect the customer's privacy", which "remains in force". > a) If a contractual obligation is in conflict with the Baseline > Requirements, do you have a process defined to resolve that conflict? If > so, please fully describe it. Do you think this particular contractual obligation to privacy _is_ in conflict with the BRs? If so, which section? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response X
Hi Ryan, On 10/04/17 17:20, Ryan Sleevi wrote: > 1) You stated that this partner program applies to non-TLS certificates. > The audit for both STN and for the RAs fails to make this distinction. For > example, audits are listed related to the issuance of of TLS certificates. The audits linked to from the wiki page relating to E-Sign and MSC TrustGate don't seem to have any mention of TLS certificates. Can you explain which audits you are referring to above that do mention them? > 2) What technical restrictions, if any, exist to ensure that RAs do not > issue TLS certificates? This is a good question. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Issues doc updated
I have attempted to integrate the information provided by Symantec into: https://wiki.mozilla.org/CA:Symantec_Issues and started to draw some conclusions where that is warranted. There are of course still open questions from myself, Ryan and others, and so the truth relating to some incidents is not yet clear. Please let me know if you see that I have included anything inaccurate or misleading, or if an entry seems incomplete. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response V
Hi Steve, Thank you for this. Issue V was indeed somewhat confused - my apologies. I have split it into Issue V, covering GeoRoot, and Issue W, covering the RAs. On 10/04/17 15:58, Steve Medin wrote: > Separately, Symantec operates two subordinate CAs solely for NTT > DoCoMo in an enterprise PKI application. These subordinate CAs had > been considered part of the "GeoRoot" program as well, and we had > therefore excluded them (similar to the above externally operated > ones) from the list of Symantec CAs in our audits. If they were excluded from the Symantec audit, and were not one of the five GeoRoot partners who had their own audits, did these subordinate CAs fall under any audit at all in this period? > Symantec provided the letter quoted below to Google, Mozilla, > Microsoft, and Apple when we shared the Point in Time Audits on > September 6, 2016 to specifically address the GeoRoot audit status > and remediation plan. Without seeming to doubt your word, can you tell me how you supplied such a letter? Was it to certifica...@mozilla.org or directly to Kathleen? A quick search can't find it in my email archive, so a recipient, Subject and Date for the communication would be most appreciated. > All of Certisign's audits are both WebTrust for CAs and SSL Baseline > and were unqualified. The Certisign audit provided was this one: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929 It does say that Certisign complied with the Network Security Guidelines but doesn't mention the BRs and, somewhat confusingly, also says: "This report does not include any representation as to the quality of CERTISIGN - CA's services beyond those covered by the Trust Service Principles and Criteria for Certification Authorities..." which suggests this audit is only a WebTrust for CAs audit, not a BR audit. Are there audit documents missing which show that they were BR-audited? Can you clarify? > Certsuperior's audits state that their scope was WebTrust for SSL > Baseline but do not state WebTrust for CAs. Prior to 2016, > Certsuperior provided WebTrust SSL Baseline audits from an unlicensed > auditor. Symantec's compliance organization identified the issue in > 2016. For 2016, Certsuperior provided a qualified audit by Deloitte, > a WebTrust licensed auditor in Mexico. Certsuperior's audit led to > immediate sanction to solve the issues detected within 90 days and to > provide a Point in Time audit. They provided such audit and it was > unqualified. Further, Deloitte is required to examine certificate > issuance as a normal part of the WebTrust program and they did not > cite any problems with Certsuperior's validation work in either > audit. Accordingly, we believe certificate issuance was inspected. Are you saying that none of the deficiencies identified at Certsuperior, in Symantec's view, had a material effect on the quality of certificate issuance? Given that Deloitte pointed out that the CPS was illegible and there was a "lack of implemented and documented control for requested validations sent by authorized personnel", on what grounds do you state that "Deloitte ... did not cite any problems with Certsuperior's validation work"? If they can't read the CPS, how can they tell if Certsuperior is following it? > Certisur's audits were WebTrust for CAs only. Symantec's compliance > organization identified the issue and has requested that Certisur's > next audit for calendar year 2016 explicitly include the criteria in > both WebTrust for CAs and WebTrust Baseline. All audits received > were unqualified and performed by a licensed WebTrust auditor. How long has it been the case that they did not have a BR audit? > CrossCert's audits were WebTrust for CAs only through 2015. Same question. Does Symantec agree that these RAs should have had a Baseline audit for all periods when they were operating? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
Hi Ryan, On 10/04/17 17:03, Ryan Sleevi wrote: > 2) You stated that "browsers didn't process certificate policy extensions > content during path building". This fails to clarify whether you believe it > was a Baseline Requirements violation, which makes no such statements > regarding policy building. Further, no such browser has, except for EV, > made use of any policy IDs beyond path building. Can you clarify: are you asking if Steve believes that the BRs require _browsers_ to do such processing of certificate policy extensions? Or are you asking him if he believes that including such extensions in the cross-cert was a BR violation? Or if he believes that cross-certifying into a hierarchy which relies upon such extensions is a BR violation? Or something else? :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions for Symantec
Hi Steve and Rick, Just to confirm: even after reviewing your extensive responses to the issues list, I feel that all the 8 questions on my questions list are still outstanding and require answers. Thanks :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On 13/04/17 17:43, Jeremy Rowley wrote: > Because the certificate improperly included Symantec's BR-compliance OID. If > the cert wasn't a BR-covered certificate but included the BR compliance OID, > then the cert was still mis-issued and should be disclosed. But that was not the reason they gave for it being misissued; they only noticed that when someone else pointed it out to them. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On 21/04/17 10:12, Nick Lamb wrote: > I'm not so uncomfortable with it that I want Mozilla to try to get it > stopped, but I think signalling some residual discomfort here is > worthwhile until somebody has thought through a good policy, and > preferably at least got the big CAs to go along with it in principle > even if we don't have it in formal Mozilla policy or the BRs. This is all a bit inchoate :-) Can you give me any idea at all of what such a policy would look like? Requiring OV is not an option IMO. Are we going to do anything differently, today, for a CA who issues DV wildcard certs compared to one who is not? I don't believe so. And if that's the case, I can't see any value in having this issue on the list. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
