Re: Certificate for com and it
On 08/02/18 13:47, Hanno Böck wrote: > Is a revoked intermediate cert a license for operating a yolo CA that > signs everything? Given the fragility of revocation checking I'd find > that a problematic precedent. In this case, the certificates are revoked in Firefox via OneCRL and Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be noticed. > The OCSP seems operational and replies with "Good" and the issuance > happened before it's being added to OneCRL. If the cert itself has not been revoked by its issuer, "Good" is an entirely reasonably response... > I don't find a reference why this intermediate had been added to > OneCRL, but I think this deserves more clarification what's going on > here. OneCRL additions normally have an associated bug but I can't see one for this... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissuance/non-compliance remediation timelines
On 07/02/18 15:14, Alex Gaynor wrote: > That said, given the issues Paul highlighted in his original mail (which I > wholeheartedly concur with), it seems the place to focus is the folks who > are getting Ds right now. Therefore I think the essential part of your > email is your agreement that CAs which are persistently low performing need > to be recognized and potentially penalized for the sum total of their > behaviors. This is, in a reasonably strong sense, what happens now. We require each incident in which a CA is involved to be documented in a public bug, so all can see the timeline, outcomes, how the CA reacted and other factors which might be taken into account when determining a CA's competence. Occasionally, we decide that some CA's list of recent[0] problems is sufficiently serious[0] that we need to run an investigation. We do so, and invite the CA to more formally comment on the sum total of the problems. We assess the responses and the style and level of response, and make a determination[0]. This is what happened to WoSign, Symantec and PROCERT: https://wiki.mozilla.org/CA:WoSign_Issues https://wiki.mozilla.org/CA:Symantec_Issues https://wiki.mozilla.org/CA:PROCERT_Issues I therefore expect and hope that CAs in our program have noted what happened in those cases, particularly PROCERT (which is probably the clearest case of simple "general incompetence" that we have had), and want to make sure they are not next. Gerv [0] Yes, this is vague. But so is the concept of "trust". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ccadb.org
On 30/01/18 00:48, James Burton wrote: > I was doing research on the ccadb.org site and was surprised to find that > the site is running only in HTTP and is not using HTTPS. Now, I understand > that GitHub pages don't support HTTPS for custom domains but you could > always use CloudFlare for HTTPS support in the meantime until GitHub > enables HTTPS for custom domains. The Cloudflare solution turns out not to be ideal for Mozilla IT. They have instead proposed another solution using AWS and Nubis, which is being implemented in the (infrastructure-confidential) bug https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 . I've pinged the bug so hopefully something should happen soon. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Responses to the November CA Communication
On 24/01/18 21:41, Wayne Thayer wrote: > First off, I question if we would really use lesser sanctions more often. I > think we would still want to coordinate their implementation with other > user agents, and that is a tedious process. I think it's important for root programs to make independent decisions, therefore I would be uneasy about too high a level of coordination with regard to CA sanctions. Once two root programs have both decided to take similar action, it is reasonable to coordinate to make sure the impact of the two requirements is not disproportionate compared to the impact each individual root program is attemping to have. But that's different from saying: "We are going to sanction CA Foo - are you in?", or even "We'll sanction CA Foo if you do." Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Responses to the November CA Communication
On 24/01/18 13:56, Ryan Sleevi wrote: >> more frequently when requirements change. I propose that we require CAs to >> update their CPS to comply with version 2.5 of the Mozilla root store >> policy no later than 15-April 2018. I think Ryan is right here; the deadline for complying with most of the new changes was "immediately" - in part, that was due to the nature of the changes, in that this was possible, and also we put out a call for "does anyone need an implementation period for any of these things", and the only response was from Globalsign, which led to the modification of the email intermediate compliance dates. I realise that updating one's CPS to match changes in practice can't be done overnight - there are change control procedures - but taking 15 months is ridiculous. We should get back to Microsec and tell them that this is unacceptable. If we do set a "new" deadline for CPS updates, it should be closer than mid-April, and we should update our policy to make it clear how fast we expect CPSes to be updated in the wake of "immediate" new requirements - either from a new version of the policy, or from some emergency action we take. > 2 should be inconsequential, but 1 has a very real effect - unless/until > the CA updates their CP/CPS to explicitly state what methods they are using > (implicitly disavowing the 'any other method'), then a CA can receive a > fully compliant audit, despite actively issuing certificates using 'any > other method', in contravention of Mozilla Policy. Ryan: I thought you had previously made the case that all CAs actually had to abide by the latest version of the BRs? If that is so, then surely your point above is incorrect? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On 24/01/18 22:19, Jonathan Rudenberg wrote: > While these CAs might want six months, it’s not clear that a good > argument has been made for this. Let’s Encrypt stopped validating > using the TLS-SNI-01 method under two hours after learning that there > was a *potential* security vulnerability in the validation method. > Why should we expect any less from other CAs? We should err on the > side of protecting users, not CAs using insecure validation methods > that don’t even stand up to a small amount of adversarial scrutiny. Six months may or many not be the right timeline, but I don't think it's fair to compare removing an option in an automated process (which was, in fact, subsequently restored for existing customers within a few days) with retraining all your validation specialists to use a different manual process. Such work cannot be done in 2 hours. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign certificate with far-future notBefore
On 24/01/18 18:02, Doug Beattie wrote: > Can we consider this case closed with the action that the VWG will > propose a ballot that addresses pre and postdating certificates? Yes. I don't believe anyone has suggested that Globalsign broke a formal rule, either in the BRs or Mozilla's requirements. Thank you for engaging with us on this topic. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Responses to the November CA Communication
On 24/01/18 16:44, Wayne Thayer wrote: > In the past, new policy versions have not had a clearly defined future > effective date. That seems to have led some CAs to interpret the timing for > making changes to be "whenever we get around to it" instead of the intent > of "the policy is effective immediately and we expect you to comply with it > as soon as possible". Given this abuse, I'd prefer to put a date on each > new version of the policy by which CAs are expected to comply with it. This > date would be 2-3 months after the policy was announced, but would also > allow specific carve-outs for changes that take longer. We do actually do that, it's just not written in the policy itself. See: https://wiki.mozilla.org/CA/Root_Store_Policy_Archive which gives all the publication dates and compliance dates. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign certificate with far-future notBefore
Hi Doug, Thanks for the quick response. On 24/01/18 11:52, Doug Beattie wrote: > In the case below, the customer ordered a 39 month certificate and > set the notBefore date for 2 months into the future. Momentary 2017/2018 confusion in my brain had me thinking that this was further into the future than it actually was. But yet still, it is the other side of a reduction in certificate lifetime deadline. > We permit customers to set a notBefore date into the future, possibly > for the reason listed below, but there could be other reasons. So if a customer came to you today and renewed their certificate for www.example.com with validity from 24th Jan 2017 to 24th Apr 2020 (perfectly fine), and then requested a second 39-month certificate valid from 24th Apr 2020 to 24th July 2023, would you issue this second one? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign certificate with far-future notBefore
On 24/01/18 04:57, David E. Ross wrote: > I am not sure about prohibiting forward-dating the notBefore date. I > can picture a situation where an existing site certificate is going to > expire. The site's administration decides to obtain a new certificate > from a different certification authority. Because of various > administrative processes, the switch to the new site certificate cannot > be accomplished quickly (e.g., moving the server); so they establish a > notBefore date that is a month in the future. Why would that be _necessary_? What would go wrong if the cert was cut with a notBefore of the current date, apart from the fact that they'd need to renew it a month earlier? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign certificate with far-future notBefore
Hi Jonathan, On 23/01/18 22:55, Jonathan Rudenberg wrote: > A certificate issued by GlobalSign showed up in CT today with a notBefore > date of March 21, 2018 and a notAfter date of April 23, 2021, a validity > period of ~1129 days (more than three years). Thank you for pointing this out. This does seem at first look like an attempted end-run around the 825-day validity period restriction which comes into effect soon. Perhaps GlobalSign would care to comment here? If not, I can file a bug and make a formal request. > 1) The Root Store Policy should explicitly ban forward and back-dating the > notBefore date. I am not opposed to this, but I would want to allow CAs to make representations about when this is necessary so we can see if any exceptions do actually need to be made. But a general rule might be a good idea. > 2) Firefox should implement a technical check to enforce the validity period > so that issuance practices like this do not impact users (see > https://bugzilla.mozilla.org/show_bug.cgi?id=908125) Does Chrome already do this? If so, I might expect this cert, once it becomes valid, not to work in Chrome... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Responses to the November CA Communication
On 24/01/18 00:47, Wayne Thayer wrote: > more frequently when requirements change. I propose that we require CAs to > update their CPS to comply with version 2.5 of the Mozilla root store > policy no later than 15-April 2018. I think we should have a more general stipulation that Mozilla does not consider it reasonable to take more than N months to make an update to a CPS, with N being a number like 3 or 2. Now, a particular change my require code changes as well, and the CPS may only be updated when those are made, and that might take longer - that's fine. But if the requirement is e.g. "add some extra contact information", that's not fine. CAs should not be in the habit of having processes where their CPSes are only updated yearly. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 19/01/18 13:20, Jakob Bohm wrote: > My suggestions are only meant to inspire formal rules written / chosen > by module leaders such as you. But the entire point of this discussion is that we are pointing out it's hard to make such rules in the way you have just made them without being arbitrary, and arbitrariness is something we want to avoid. So giving us an example arbitrary ruleset is not really moving the discussion forward much. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 19/01/18 01:05, Jakob Bohm wrote: > On 18/01/2018 11:01, Gervase Markham wrote: >> On 17/01/18 19:49, Jakob Bohm wrote: >>> 3. Major vertical CAs for high value business categories that issue >>> publicly trusted certificates at better than EV level integrity. For >> >> How do you define "major"? And "high value business category"? > > Major would be the biggest 1 to 3 of their kind, ignoring any covering > only a small fraction of the relevant web site/e-mail population even if > in the top 3. Also any not doing this globally is not major. I guess my question was ambiguous. Clearly it's very easy to come up with arbitrary definitions for these things, but what's the rationale? Why 1-3? Why not 1-8? > High value business category would be a category where web users have an > extremely high need for genuineness. Banks/central payment systems > would be the canonical example, with the VISA CA/SET combination as a > possible historic example (noting that it looks like they don't > currently qualify even if they did in the past). You've just shifted the definitional problem to the words "extremely high need for genuineness". Proving examples of what you personally mean by these terms is not sufficient to make a definition, unless the Mozilla policy becomes "whatever Jakob Bohm decides". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 18/01/18 14:24, Ryan Sleevi wrote: > Or, conversely, that we cannot discuss inclusion policies in isolation from > discussion root policies - we cannot simultaneously work to strengthen > inclusion without acknowledging the elephant in the room of the extant CAs. We aren't necessarily "strengthening" inclusion, in the sense of making it harder to get in - the outcome of the discussion could be a loosening. If we come up with new inclusion criteria and some existing CAs do not meet them, we would need to have a separate discussion to decide what to do, with the main options being grandfathering them in, restricting them in some way, or removing them. > Isn't this effectively the VISA situation? When were their first audits - > late 2016 / early 2017? I'm not certain; I'll ask Kathleen. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
Hi Ryan, On 18/01/18 13:55, Ryan Sleevi wrote: > I do want to point out that you are substantially changing the goals from > what Wayne posited. That is, you have moved the goalpost from being > 'objective' to being what is 'fair', and 'fair' will inherently be a > subjective evaluation. One of my goals in this discussion is to record some of the thoughts I had on the topic, of which this is one. Those thoughts are far from unchallengeable - as you have recognised, since you are challenging one of them :-) > Was it your intent to redefine the problem like that? If not, do you have > those concerns about the objective measures, or is your goal to find > objective measures which you subjectively believe to be 'fair'? For > example, an objective measure would be "Paid for a 2-week vacation for > Gervase Markham and family every year to a location of their choosing", but > I suspect that you might argue it's subjectively 'not fair'? If every CA had to do it, it would both be an objective measure and subjectively fair. (Although one could argue it was unfair if I asked one CA to send us to Bogor Regis and another to send us to the Maldives. it would also mean a maximum of 26 CAs in the program at one time, and in the past we have decided against a hard numerical limit.) I would like to find a set of objective measures which the group considers as a whole to be "fair", in that the objective measures do not use criteria which are irrelevant to operating as a CA (such as buying my family a holiday). This may not be possible, of course - we will see - but that doesn't stop me wanting it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 18/01/18 13:53, Ryan Sleevi wrote: > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at > the detriment to both user security and the ecosystem. If your goal is for > policies that do not favor incumbents, then it seems a significantly > different discussion should happen - and proposals such as Jonathan's > inherently provide a way to normalize that field. If Jonathan's proposal were applied to all CAs, it might well reduce incumbent advantage. But that would be a different discussion from inclusion criteria. If it were applied only to new CAs, it would be relevant to the current discussion - but then it would entrench incumbent advantage. > A prime example, recently highlighted in ongoing CA inclusion discussions, > is whether or not a CA must have an unbroken series of audits since their > key was created (the PITRA). Yes. It seems that we have come to the position that it does not necessarily have to. But I would raise an eyebrow at a root that had been operating for 10 years and had only got its first set of audits last week. > Obviously, during the introduction of the > Baseline Requirements, this was not the case for any incumbents - and > Mozilla further granted an effective 3 years for incumbents beyond the BRs > effective date to come up to date, while simultaneously examining new CAs > against the modernized criteria. I'm not sure it was that long, and even if it was, I think this criticism is a little harsh given that we have been at the forefront of giving the BRs any teeth at all. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 17/01/18 19:49, Jakob Bohm wrote: > 3. Major vertical CAs for high value business categories that issue > publicly trusted certificates at better than EV level integrity. For How do you define "major"? And "high value business category"? > 4. Selected company CAs for a handful of too-bit-to-ignore companies > that refuse to use a true public CA. So you think Mozilla's policy should include formal acknowledgement that some companies are too big to ignore? How do you decide which companies are in this category? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 19:14, Ryan Hurst wrote: > Since Google's PKI was mentioned as an example, I can publicly state > that the plan is for Google to utilize the Google Trust Services > infrastructure to satisfy its SSL certificate needs. While I can not > announce specific product roadmaps I can say that this includes the > issuance of certificates for Google offerings involving hosting of > products and services for customers. This is an interesting situation because it points to an interesting ramification of a requirement which is anything like "issues certs to the public". We can compare large companies who happen to be in the cloud hosting business (e.g. Google, Amazon, Microsoft) with those that are not. The former category can pass a "issuing certs to the public" test and so qualify for inclusion, and can then use that same infra to issue their internal certs, or certs for their own public-facing domains and hostnames. A large company which happens not to be in the cloud hosting business cannot pass that test, and so has to use a 3rd party CA for their cert requirements. One could argue that deciding whether a large tech company gets the convenience of a self-hosted root based on whether they provide a particular service is not very fair. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 15:41, Peter Bowen wrote: > In the interest of transparency, I would like to add one more example > to your list: > > * Amazon Trust Services is a current program member. Amazon applied > independently but then subsequently bought a root from Go Daddy > (obvious disclosure: Wayne was VP at Go Daddy at the time). So far > there is no public path to bring Amazon a public key/CSR you generate > on you own server and have Amazon issue a certificate containing that > public key. The primary path to getting a certificate issued by > Amazon is to use AWS Certificate Manager. That being said, we have > issued certificates to hundreds of thousands of domains and Mozilla > telemetry data shows they are being widely used by users of Mozilla > software products. IOW, you can't bring your CSR to Amazon and get a certificate, but you can bring your _domain_ to Amazon and get a certificate. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 15:13, Jonathan Rudenberg wrote: > I like this concept a lot. Some concrete ideas in this space: > > - Limit the validity period of root certificates to a few years, so that the > criteria can be re-evaluated, updated, and re-applied on a rolling basis. Are you saying we should do this for new entrants only? If so, surely that would give existing CAs a significant competitive advantage? Or, if not, what is the relevance of your point to the question under consideration? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should focus less on the questions of whether a CA > is "appropriate" or "deserving" of participation in the Mozilla Root > Program, and more on whether they are willing and able to fulfill the > expectations of them as a steward of global trust on the internet. If you ask any applicant "are you willing and able to fulfil what is expected of you as a steward of global trust on the Internet?", and they know they have to say "Yes" to get in, they will say "Yes". So is the upshot of your position that anyone who wants to apply can get in? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB disclosure of id-kp-emailProtection intermediates
On 17/01/18 10:25, Rob Stradling wrote: > However, the Stable version of the Mozilla Root Store Policy [2] still > says 15th January 2018. > > Surely the Stable version of the Policy is in force and the Draft > version is not yet in force? > > Perhaps Mozilla could consider publishing a v2.5.1 of the Policy that > (compared to v2.5) simply updates this disclosure deadline? We published an erratum, and have noted in every discussion of this issue that the dates have changed. https://wiki.mozilla.org/CA/Root_Store_Policy_Archive Perhaps we should have done a 2.5.1 but at the time I thought telling everyone would be sufficient. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure
On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote: > We discussed a similar approach (using CAA) on our community forum, > and concluded we don't want to pursue it at this time: > https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT > record would probably work more widely than CAA, but it would still > be encouraging further integration with TLS-SNI-01, when we really > want to encourage migration away from it. Right now it's our feeling > that the account and renewal whitelisting should mitigate most of the > pain of migrating away, but experience and feedback from subscribers > will help inform that over time. Why would you want to continue migrating away if it were based on a self-serve whitelist? Would that not re-secure the method? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment
On 12/01/18 14:52, Doug Beattie wrote: > For shared IP address environments, it may be possible to receive a > certificate for a domain you don’t actually control, but a number of > things need to happen in order for this to be successful. What can > go wrong? Doug: what do you see as the exact differences between your setup and the TLS-SNI-01 configuration? It seems to me that both are vulnerable in the same circumstances (i.e., hosting provider has many users hosted on the same IP address, and users have the ability to upload certificates for arbitrary names without proving domain control). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure
On 10/01/18 17:39, Matthew Hardeman wrote: > Here again, I think we have a problem. It's regarded as normal and > acceptable at many web host infrastructures to pre-stage sites for > domain-labels not yet in use to allow for development and test deployment. I agree that "no unknown domain names" is hard to implement "No domain names owned by another customer" is easier and doesn't cause the problems you raise. "No acme.invalid" is even easier. > In the course of adopting the 10 blessed methods, did any of the methods > move forward with the expectation that active effort on the part of non-CA > participants versus the status quo would be required in order to ensure the > continuing reliability of the method? "Active effort vs. the status quo" is a skewed framing because security always requires active effort in the face of change, new entrants etc. A new entrant in the email market has to make an active effort to make sure that the special addresses are not claimable, even though that issue has been known for years. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure
On 10/01/18 17:04, Matthew Hardeman wrote: > That seems remarkably deficient. No other validation mechanism which is > accepted by the community relies upon specific preventative behavior by any > number of random hosting companies on the internet. I don't think that's true. If your hosting provider allows other sites to respond to HTTP requests for your domain, there's a similar vulnerability in the HTTP-01 checker. One configuration where this can happen is when multiple sites share an IP but only one gets port 443 (i.e. the pre-SNI support situation), and it's not you. Or, if an email provider allows people to claim any of the special email addresses, there's a similar vulnerability in email-based methods. The "don't allow acme.invalid" mitigation is the easiest one to implement, but another perfectly good one would be "don't allow people to deploy certs for sites they don't own or control", or even "don't allow people to deploy certs for sites your other customers own or control". Put that way, that doesn't seem like an unreasonable requirement, does it? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure
On 10/01/18 14:34, Jakob Bohm wrote: > Enforcement on shared hosting systems would be easier if the TLS-SNI-01 > ACME mechanism used names such as > 1234556-24356476._acme.requested.domain.example.com > since that would allow hosting providers to restrict certificate uploads > that claim to be for other customers domains. Hosting providers can simply refuse to accept uploads of any certificate which contains names ending in "acme.invalid". AIUI, this is Let's Encrypt's recommended mitigation method. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Changes to CA Program - Q1 2018
On 10/01/18 00:23, Kathleen Wilson wrote: > I would like to thank Aaron Wu for all of his help on our CA Program, > and am sorry to say that his last day at Mozilla will be January 12. I > have appreciated all of Aaron’s work, and it has been a pleasure to work > with him. Seconded. > I think this is a good time for us to make some changes to Mozilla’s > Root Inclusion Process to improve the effectiveness of the public > discussion phase by performing the detailed CP/CPS review prior to the > public discussion. The goal of this change is to focus the discussion > period on gathering community input and to allow the process to continue > when no objections are raised. This seems fine to me. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Potential problem with ACME TLS-SNI-01 validation
On 10/01/18 02:26, j...@letsencrypt.org wrote: > We've received a credible report of a problem with ACME TLS-SNI-01 validation > which could allow people to get certificates they should not be able to get. > While we investigate further we have disabled tls-sni-01 validation. > > We'll post more information soon. https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Serial number length
Hi, On 29/12/17 06:24, Jakob Bohm wrote: > 1. Do all recently issued certificates have to contain at least 64 bits > of randomness in their serial numbers? Yes. (References given by others.) > 2. Is it acceptable for a CA to satisfy this requirement by generating > random 64 bit serial numbers and checking if there is a certificate > with that random serial before using it? IMO Yes. The requirement is specifically to include 64 bits of output from a CSPRNG. Bits don't stop being from a CSPRNG just because they've compared unequally with a list of other sets of bits. > 3. Or would the elimination in #2 reduce the entropy of such serial > numbers to slightly less than 64 bits (since there are less than 2**64 > allowed values for all but the first such certificate)? Technically, it would, but I don't think that's a problem as the requirement is written, and I don't think it's a problem in practice because the entropy reduction is so slight and the error margin is intentionally large. 2^64 is 18,446,744,073,709,552,000. Even if you issue a billion certificates, the entropy reduction is 0.001%. (May be off by an order of mag. or two, but roughly that.) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Dashboard and Study on CAA Adoption
Hi Quirin, On 15/12/17 15:09, Quirin Scheitle wrote: > The results, paper, and a dashboard tracking CAA adoption are available under > > https://caastudy.github.io/ Belatedly, thank you and your colleagues for doing this excellent work. It is interesting that you have received no iodef messages at all. I can imagine CAs deprioritizing that work in favour of getting their implementations right. I can see a time, when CAA implementations have settled down and are reliable, that we might look at mandatory reporting of attempted misissuance. CAs are already able to use CA-specific tags to restrict particular validation methods and certificate types; this is something I think it's reasonable to let the market provide if there is demand. The DNS operator privilege is there because it doesn't make too much sense for an organization to ask itself for permission to issue. I would expect CAs to be storing the results of their CAA lookups in their issuance logs, in sufficient detail for them to be checked later, even if they are not published. I share your hope that the deployment and use of CAA, and the accuracy and consistency of checking, will improve in the days ahead. It will be fascinating if you are able to repeat this research in six or twelve months time. One other quote: "For 1 domain, our scans showed a CAA configuration that consistently did not permit any CA to issue, yet a certificate was issued during this time. Upon inquiry, the domain name holder confirmed that they had fully automated their certifi- cate issuance process, including automatic reconfiguration of CAA records for a brief time period." That's pretty awesome :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Mozilla CA Team availability
The Mozilla CA team will have limited availability over the Christmas and New Year period, and so you should not expect us to engage substantively in complex debates, make controversial decisions, or otherwise act as if we were functioning at full strength :-) We hope that normal service will be resumed in mid-January. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA generated keys
On 15/12/17 16:02, Ryan Hurst wrote: > So I have read this thread in its entirety now and I think it makes sense for > it to reset to first principles, specifically: > > What are the technological and business goals trying to be achieved, > What are the requirements derived from those goals, > What are the negative consequences of those goals. > > My feeling is there is simply an abstract desire to allow for the CA, on > behalf of the subject, to generate the keys but we have not sufficiently > articulated a business case for this. I think I'm in exactly this position also; thank you for articulating it. One might also add: * What are the inevitable technical consequences of a scheme which meets these goals? (E.g. "use of PKCS#12 for key transport" might be one answer to that question.) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
On 15/12/17 15:50, Tim Shirley wrote: > I don’t see how you can argue that the EV “seatbelt” breaks 100% of > the time. I know my bank uses an EV cert. Any time I come across a > site claiming to be my bank but lacking an EV cert, and my browser > shows me that distinction, is a time when the seatbelt saves me, > through that extra signal that alerts me that something isn’t right. Unless you are using a browser (e.g. a mobile browser) which doesn't show EV indicators, for UX choice or even technical reasons. So you need to know which browsers show EV in the first place. And then, if you are using Chrome, AIUI an OCSP failure will lead to a downgrade to no-EV, so you have to eliminate the possibility as well. As things stand, for better or worse, there are multiple circumstances where the EV indicator might not show even though it's your real bank. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
On 13/12/17 11:58, Tim Shirley wrote: > So many of the arguments made here, such as this one, as well as the recent > demonstrations that helped start this thread, focus on edge cases. And while > those are certainly valuable to consider, they obscure the fact that “Green > Bar” adds value in the mainstream use cases. If we were talking about how to > improve EV, then by all means focus on the edge cases. The thing I don’t see > in all this is a compelling argument to take away something that’s useful > most of the time. My concern with this argument is that it's susceptible to the criticism that Adam Langley made of revocation checking: https://www.imperialviolet.org/2012/02/05/crlsets.html "So [EV identity is] like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it." Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
On 11/12/17 17:00, Ryan Sleevi wrote: > Fundamentally, I think this is misleading. It presumes that, upon > something bad happening, someone can link it back to that certificate > to link it back to that identity. If I was phished, and entered my > credentials, there's no reason to believe I've maintained the record > details including the phishing link to know I was phished. Are users > supposed to spleunk their HTTP cache or maintain complete archives of > every link they visited, such that they can get the cert back from it > to aid an investigation? This is something that has always worried me about the EV value proposition. Even if it worked perfectly, once one has realised one has been scammed, one would want to find the cert again to know where to serve the lawsuit papers or send the police. Unless your browser caches all EV certs for sites you've ever visited in the past month, and provides some UI for querying that cache, then that's not necessarily going to be possible. So having the info about the site owner in the cert isn't actually useful. CT does address this to a degree, but only to a degree. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA generated keys
Hi Tim, The more I think about it, the more I see this is actually a interesting question :-) I suspect the first thing Mozilla allowing this would do would be to make it much more common. (Let's assume there are no other policy barriers.) I suspect there are several simpler workflows for certificate issuance and installation that this could enable, and CAs would be keen to make their customers lives easier and reduce support costs. On 09/12/17 18:20, Tim Hollebeek wrote: > First, third parties who are *not* CAs can run key generation and escrow > services, and then the third party service can apply for a certificate for > the key, and deliver the certificate and the key to a customer. That is true. Do you know how common this is in SSL/TLS? > I'm not > sure how this could be prevented. So if this actually did end up being a > Mozilla policy, the practical effect would be that SSL keys can be generated > by third parties and escrowed, *UNLESS* that party is trusted by Mozilla. Another way of putting it it: "unless that party were the party the customer is already dealing with and trusts". IoW, there's a much lower barrier for the customer in getting the CA to do it (trust and convenience) compared to someone else. So removing this ban would probably make it much more common, as noted above. If it's something we want to discourage even if we can't prevent it, the current ban makes sense. > Second, although I strongly believe that in general, as a best practice, > keys should be generated by the device/entity it belongs to whenever > possible, we've seen increasing evidence that key generation is difficult > and many devices cannot do it securely. I doubt that forcing the owner of > the device to generate a key on a commodity PC is any better (it's probably > worse). That's also a really interesting question. We've had dedicated device key generation failures, but we've also had commodity PC key generation failures (Debian weak keys, right?). Does that mean it's a wash? What do the risk profiles look like here? One CA uses a MegaRNG2000 to generate hundreds of thousands of certs.. and then a flaw is found in it. Oops. Better or worse than a hundred thousand people independently using a broken OpenSSL shipped by their Linux vendor? > With an increasing number of small devices running web servers, > keys generated by audited, trusted third parties under whatever rules > Mozilla chooses to enforce about secure key delivery may actually in many > circumstances be superior than what would happen if the practice is banned. Is there a way to limit the use of this to those circumstances? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 09:05, Gervase Markham wrote: > We understand that WoTrus (WoSign changed their name some months ago) > are working towards a re-application to join the Mozilla Root Program. > Richard Wang recently asked us to approve a particular auditor as being > suitable to audit their operations. Thank you to everyone who contributed to this discussion in a thoughtful and measured way. Mozilla has emailed WoTrus and Qihoo 360 with our summary of the sentiment of the group, which we hope will be useful to them in making their future plans. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Anomalous Certificate Issuances based on historic CAA records
On 30/11/17 14:52, Ryan Sleevi wrote: > I think that, as CAA deployment becomes common, this pattern will be > not-uncommon. I would hope we don't sound false alarms when it does. After a little time (as it does seem some bugs are still being shaken out), I am considering having Mozilla adopt a policy either of: a) not accepting CAA violation reports from people other than the owners of the domain in question; or b) automatically believing the CA if they post a log which shows their view of the DNS at the time of issuance. We could start with b), but if CAs get a high load of reports still, we could move to a). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Firefox Mobile - Which Trust Store?
On 27/11/17 19:50, Myers, Kenneth (10421) wrote: > Does Firefox mobile use the NSS trust store? Yes, on Android. It uses the OS trust store on iOS. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names
On 24/11/17 11:37, Rob Stradling wrote: > When issuing a "single domain" certificate to (for example) > www.example.com or *.example.com, it's fairly common practice for CAs to > also include in the certificate a SAN.dNSName for the "base domain" > (e.g., example.com). (Similarly, if the certificate request is for > example.com, some CAs will add a SAN.dNSName for www.example.com). IMO these two processes are not at all "similar". Validate example.com -> add "www.example.com": seems fine to me, and a reasonable accommodation to a common customer desire. Validate www.example.com -> add "example.com": not at all fine. Validate *.example.com -> add "example.com": still dodgy IMO. I seem to remember we have come across this before, and I thought we said it was not to be done. But perhaps that didn't make it into our policy. Do we need to add it? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names
On 24/11/17 11:37, Rob Stradling wrote: > When issuing a "single domain" certificate to (for example) > www.example.com or *.example.com, it's fairly common practice for CAs to > also include in the certificate a SAN.dNSName for the "base domain" > (e.g., example.com). (Similarly, if the certificate request is for > example.com, some CAs will add a SAN.dNSName for www.example.com). IMO these two processes are not at all "similar". Validate example.com -> add "www.example.com": seems fine to me, and a reasonable accommodation to a common customer desire. Validate www.example.com -> add "example.com": not at all fine. Validate *.example.com -> add "example.com": still dodgy IMO. I seem to remember we have come across this before, and I thought we said it was not to be done. But perhaps that didn't make it into our policy. Do we need to add it? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Anomalous Certificate Issuances based on historic CAA records
Hi Quirin, Thank you for your work on this topic. I would be grateful if you could file Bugzilla bugs in the Misissuance component as follows, giving your evidence of misissuance: On 22/11/17 23:50, Quirin Scheitle wrote: > 1) Mix of wildcard and non-wildcard DNS names in SAN > Batch: https://misissued.com/batch/32/ > Description: best confer > https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ One bug per CA, please. > 4) Apparent non-evaluation of CAA records > Batch: https://misissued.com/batch/33/ > Description: These cases appear as pretty straight-forward that they > should not have been issued, but > there might be good explanations One bug for the two Comodo certs, one for the Camerfirma cert. Thank you, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 21:15, uri...@gmail.com wrote: > In particular, why would QiHoo 360 shut down efforts by Startcom, run > by a relatively trusted member of the community, Inigo Barreira, to > be accepted as a CA; and instead favor WoTrus, run by Richard Wang, > an explicitly UN-trusted member of the community, to be accepted as a > CA. Well, I don't think I'm saying anything controversial if I point out they shut down StartCom because (by demonstration) they have the ability to do so, and they saw (according to their statement) that the road to acceptance was too long, rocky and uncertain for them. It was, it seems to me, a business decision. Keeping it going costs money. They went out of their way to state they are not unhappy with Inigo. Why do they allow WoTrus to continue to operate? That question presumes that they have the power to stop it operating. Whether they have that power or not can probably only be determined by looking very carefully at the ownership structure, and may involve needing to see documents which are not public. So I don't think you can assume it's as simple as "they like WoTrus and they don't like StartCom". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 18:00, Ryan Sleevi wrote: > I think an important part of this discussion is trying to understand to > what side of Hanlon's razor did WoSign's actions fall (or, to that matter, > of any CA). If it was incompetence, is there sufficient explanation for how > such incompetence happened? If there sufficient evidence that both the > specific incident and any underlying causes have been remediated? > Alternatively, if we allow it to be attributed to malice (or, for that > matter, greed), is it possible to design a system of trust that is robust > against such considerations? If not, is it an acceptable risk to take going > forward. If we can, what are those controls and expectations? While I do not want to make this discussion entirely about specific people, as Mozilla's investigator of the issues at the time I am satisfied that WoSign's actions at the time were taken with full knowledge - that is, they were not due to incompetence. And those decisions were overseen and approved by individual(s) who still control WoSign/WoTrus. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 17:03, Matthew Hardeman wrote: > approval in terms of community buy-in. The downside, of course, is that > while this alternative pre-discussion allows for discussion of the nebulous > concept of "trust" and integrity, it actually denies the community those > matters which can be most objectively evaluated -- the CPS, the subscriber > agreements, certificate policy, auditor's opinions, etc. (which makes > sense -- the development of these is pricey). That's a fair point. Let us assume for the sake of discussion that all of those things are standard and unobjectionable in themselves. > I suppose, in summation, I believe this conversation only matters if we're > really trying to have a discussion about trust and defining trust and > importance of trust and whether there is a way that this CA can be trusted. Yes. I think that's a fair summary. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbidden Practices: Subscriber key generation
On 14/11/17 21:53, Doug Beattie wrote > The question is, if we issue Code Signing certificates via P12 files > in compliance with the Code Signing standard, are we out of > compliance with the Mozilla policy? How do you recommend we respond > to this checklist question? Mozilla does not have policies relating to code signing. We would therefore expect CAs to arrange things such that their code signing activities fall outside the scope of the Mozilla policy. The scope statement in the policy section 1.1, and it seems to me that the easiest technical way to achieve this is to do code signing activities under an intermediate which is technically constrained so it cannot issue email or server certs. > And the same for S/MIME and SSL certificates. If CAs generate and > then securely distribute the keys to the subscribers using similar > methods, is that permitted provided we implement similar security, or > does that practice need to immediately stop? Your guidance in this > area would be appreciated. For SSL, I would say it needs to immediately stop. Although see: https://github.com/mozilla/pkipolicy/issues/107 For S/MIME, as you can see, the Problematic Practices page permits it. > Side question: Is there a deadline when you expect to receive > self-assessments from all CAs? We've found that complying with the > checklist means a major update to our CPS (among other things...), > and I suspect most other CAs will also need a major update. I believe Kathleen did put a date in the CA Communication. If you need more time, contact certificates@mozilla dot org with your good reasons :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 11:39, Hanno Böck wrote: > In any case: I agree these are legitimate questions, if past CA > incidents happen the documents describing them shold be properly > archived. I think having a rule that one copy of them has to be stored > on mozilla infrastructure is wise. Having been burned before by disappearing CA documents, I do tend to keep local copies of all docs (and I do of this one, although the URL now seems to be working for me). But I don't necessarily stick them in public places on Mozilla infra. However, ask me if you need one. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 11:41, Tom wrote: > https://www.wosign.com/english/about.htm has been updated with the new > name, WoTrus, and currently says "Richard Wang, CEO&CTO" Richard stated to me at one point (I can't remember whether in person or by email) that at the time of speaking, he was no longer CEO, and they were looking for a new one, but he was CXO, where the X was, I think, an O, but might have been a T. So at one point, he did assert that he was no longer CEO. It seems like, from the website, this has changed. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On 22/11/17 10:54, Jakob Bohm wrote: > Some notes about previously discussed items: Mozilla is not suggesting that WoSign has completed all of the steps. The entire point is that we want to have this pre-discussion before they make the effort to do so. > Although not listed in the Action plan in #1311824, it is noteworthy > that Richard Wang has apparently not been relieved of his other > responsibilities, only the CEO title. Was this part of the old plan > officially dropped? Mozilla did not formally require this, but it is true that as far as we can see, Richard Wang is still effectively in charge of WoSign/WoTrus. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: November 2017 CA Communication ACTION 1 April 15 2018 date question
Hi Arkadiusz, On 17/11/17 19:28, Arkadiusz Ławniczak wrote: > Thanks Gerv > > We have a situation in which our last WT audit is for the period > ending on April 14,2017. As we know the audit is valid until the next > audit is started. That is, that the next WT audit must be for period > starting on April 15,2017 and ending not later than April 14,2018. > The question is, if we have valid audit report till 14 April,2018, > shall we have been audited before that date or Mozilla will accept > the validity this year audit report? I'm afraid I don't really understand your question :-( Perhaps a diagram would help? The rules around audit dates and timings are all in our policy. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Possible future re-application from WoSign (now WoTrus)
We understand that WoTrus (WoSign changed their name some months ago) are working towards a re-application to join the Mozilla Root Program. Richard Wang recently asked us to approve a particular auditor as being suitable to audit their operations. In the WoSign Action Items bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 Kathleen wrote "WoSign may apply for inclusion of new (replacement) root certificates[1] following Mozilla's normal root inclusion/change process[2] (minus waiting in the queue for the discussion), after they have completed all of the following action items, and no earlier than June 1, 2017." However, one step in the inclusion process is the public discussion, and we have some reason to believe that this may lead to significant objections being raised. It would not be reasonable to encourage WoSign to complete all the other steps in the process if there was little or no chance of them being approved in public discussion. So Kathleen and I thought it would be best to have a pre-discussion now, in order to make sure that expectations are set appropriately. If WoTrus had completed all the action items in the bug and arrived at the public discussion part of the application, what would people say? If you raise an objection, please say if there is any way at all that you think WoTrus could address your issue. Thanks for your input, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Warning about posting via Google Groups
Dear m.d.s.p., We appear to again have a problem with messages posted via the Google Groups web UI making it to all subscribers on the list: https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 Until that problem is resolved, if you wish to post to the list, please subscribe to the mailing list version or use the newsgroup gateway: https://www.mozilla.org/about/forums/#dev-security-policy The Google Groups UI can still be used for referencing messages, and for reading the list. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: November 2017 CA Communication ACTION 1 April 15 2018 date question
On 17/11/17 00:26, Arkadiusz Ławniczak wrote: > [...] I do not see such requirement in the Policy or even by > searching m.d.s list.. Maybe I missed something. Does anybody know > where did it come from? https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md section 5.3.1. However, the dates in version 2.5 of the policy have been superceded; see erratum note on https://wiki.mozilla.org/CA/Root_Store_Policy_Archive . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Third party use of OneCRL
On 07/11/17 14:08, niklas.bachma...@googlemail.com wrote: > I'm working for a big managed security provider. We would like to > benefit from OneCRL as a means of improving our certificate > revocation checking. As in, you'd like to download one copy per day, or you'd like 100,000 clients to download one copy per day? > I could download OneCRL at > https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records. > My question is if there is a license on OneCRL or if we are free to > use it? We have not put an explicit license on the data but certainly, in keeping with Mozilla's principles of openness and sharing, it is available for all to use. However, that doesn't mean our IT team might not take action against clients making abusively large numbers of requests. So if your usage of the list might get noticed, it would be wise to talk to us first. > Further I'm wondering if Mozilla has already thought about > third party users and provides another way of getting the most recent > version of OneCRL than getting the above mentioned website and > comparing if the content has changed? What other method might you have in mind that would be better than a computer-readable highly-available web service? I suspect if you send it an If-Modified-Since or other similar headers you might also get a Not Modified response rather than another copy of the data. But look at the code for Kinto or ask the people who wrote it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Estonia e-residency instructing users not to update Firefox (on Mac)
On 02/11/17 11:39, Henri Sivonen wrote: > A Medium post claiming[1] to represent Estonia e-residency > https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52 > instructs Mac users not to update Firefox from December 15 2017 onwards. Thank you for this report; the Estonian e-residency team has updated the blog post to remove the advice about not updating Firefox. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report : GlobalSign certificates with ROCA Fingerprint
On 03/11/17 18:16, douglas.beat...@gmail.com wrote: > Here is the final incident report Thanks, Doug :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Estonia e-residency instructing users not to update Firefox (on Mac)
On 02/11/17 10:39, Henri Sivonen wrote: > A Medium post claiming[1] to represent Estonia e-residency > https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52 > instructs Mac users not to update Firefox from December 15 2017 onwards. The policy team will be making contact with the Estonian government to attempt to work out what the logic is behind this requirement and try and get the post updated as necessary. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom inclusion request: next steps
Dear Inigo, On 14/09/17 09:49, Gervase Markham wrote: > The Mozilla CA Certificates team has been considering what the > appropriate next steps are for the inclusion request from the CA > "StartCom".[0] As readers will know, this CA has previously been removed > from trust[1], and so a re-application obviously involves particular > scrutiny. In addition, several questions have been raised about the way > in which the new StartCom PKI has been operated technically[2]. This is > a proposal for the way forward, on which comments are invited. A month ago we posted the above re: StartCom, in what was officially a request for comments. The ensuing discussion did not lead us to conclude that anything we were asking for was inappropriate. So we want to formally confirm that it is indeed Mozilla's requirement that StartCom begin again with a new-new hierarchy and do the other things outlined in the original post before we will further consider a root inclusion request from StartCom. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
Hi Peter, Ryan is the chain-building expert, and others have deeper knowledge of how the new Symantec/DigiCert PKI is going to work than I do, but here's an attempt to answer your question. On 27/10/17 16:51, Peter Bowen wrote: > If DigiCert generates a new online issuing CA on 20 March 2018 and > cross-signs it using their VeriSign Class 3 Public Primary > Certification Authority - G5 offline root CA, will certificates from > this new issuing CA be trusted by Firefox? If so, what are the > parameters of trust, for example not trusted until the new CA is > whitelisted by Mozilla or only trusted until a certain date? Certificates chaining up to Symantec roots, so including that Verisign one, which have notBefore dates after June 2016 (which I assume these would) will continue to be trusted until the full removal of trust in Symantec in October 2018. They may be trusted beyond that if this new issuing CA is one of the ones DigiCert asks us to whitelist for Symantec continuity (the "Managed Partner Infrastructure"). Although I'm generally expecting DigiCert to create and submit a single list of such CAs at one time, rather than submitting them in dribs and drabs. > What about the same scenario except the new issuing CA is generated on > 30 June 2019? As the Verisign root would no longer be in our root store, certs issued by such an issuing CA would no longer ordinarily be trusted. If this were a whitelisted continuity issuing CA, it might still be trusted. If I recall correctly, the future trust parameters for those continuity CAs is undefined by the consensus plan. It says that they will continue to work until any new Symantec hierarchy is in all the root stores, but that was defined before the purchase was mooted. So it seems to me like there is now a question mark here. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Francisco Partners acquires Comodo certificate authority business
On 31/10/17 13:21, Kyle Hamilton wrote: > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business Comodo notified Mozilla of this impending acquisition privately in advance, and requested confidentiality, which we granted. Now that the acquisition is public, it is reasonable for the community to have a discussion about the implications for Mozilla's trust of Comodo, if any. However, there is also another wrinkle to iron out. Our policy 2.5 says: "If the receiving or acquiring company is new to the Mozilla root program, there MUST be a public discussion regarding their admittance to the root program, which Mozilla must resolve with a positive conclusion before issuance is permitted." I personally feel that this is a bug, in that technically it says that as soon as a deal closes and is announced, the CA has to stop issuance entirely until the Mozilla community has had a discussion and given the OK. I believe that's not reasonable and would create massive business disruption if the letter of that rule were enforced strictly. I think that when we wrote the policy, we didn't anticipate the situation where the buyer would be confidential until closing. (Compare Digimantec, where it's not.) So it would also be useful to have a discussion about what this section of the policy should actually say. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Statement on DigiCert’s Proposed Purchase of Symantec
[ Also at https://blog.mozilla.org/security/2017/10/31/statement-digicerts-proposed-purchase-symantec/ ] Mozilla’s Root Store Program has taken the position that trust is not automatically transferable between organizations. This is specifically stated in section 8 of our Root Store Policy v2.5[0], which details how Mozilla handles transfers of root certificates between organizations. Mozilla has taken an interest in such transfers, and there is the potential for trust adjustments based on the particular circumstances. The CA DigiCert has announced that it is in negotiations to acquire the CA business of Symantec[1]. This announcement was made following the decision of Mozilla and other root store programs to phase out trust in Symantec’s root certificates[2], based on a detailed investigation[3] of their old and large CA hierarchies and their behaviour and practices over the past few years. There are no plans to change this phase-out of trust in the roots owned by Symantec. While Mozilla does not intend to micro-manage any CA, the final arrangements for management and processes and infrastructure to be used by the combined company is of interest and potential concern to us. It would not be appropriate for a CA to escape root program sanction by restructuring, or by purchasing another CA through M&A and continuing operations under that CA’s name, essentially unchanged. And examination of historical corporate merger and acquisition activity, including deals involving Symantec, show that it’s possible for an M&A billed as the “purchase of B by A” to end up with name A and yet be mostly managed by the executives of B. Representatives of DigiCert have sought guidance from us on the type of arrangements which would and would not cause us concern. In a good faith effort to answer that enquiry, we can make the following, non-exhaustive statements of what would cause Mozilla concern. * We would be concerned if the combined company continued to operate significant pieces of Symantec’s old infrastructure as part of their day-to-day issuance of publicly-trusted certificates. * We would be concerned if Symantec validation and operations personnel continued their roles without retraining in DigiCert methods and culture. * We would be concerned if Symantec processes appeared to displace DigiCert processes. * We would be concerned if the management of the combined company, particularly that part of it providing technical and policy direction and oversight of the PKI, were to appear as if Symantec were the controlling CA organization in the merger. We hope that this provides useful guidance about our concerns, and note that our final opinion of the trustworthiness of the resulting entity will depend on the facts and behavior of the resulting organization. Mozilla reserves the right to include or exclude organizations or root certificates from our root store at our sole discretion. However, if the M&A activity moves forward, we hope that the list above will be helpful to DigiCert in planning for a future harmonious working relationship with the Mozilla Root Program. Gervase Markham Kathleen Wilson [0] http://www.mozilla.org/projects/security/certs/policy/ [1] https://www.digicert.com/news/digicert-to-acquire-symantec-website-security-business/ [2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ [3] https://wiki.mozilla.org/CA:Symantec_Issues ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ETSI audits not listing audit periods
On 31/10/17 00:13, Kathleen Wilson wrote: > Yes, that meets our requirement regarding stating the audit period > and if it is a period-of-time/full audit. The problem is that most > ETSI audit statements that we get do not say this. And it has been an > uphill battle for me to get ETSI audit statements to say this. But is the problem that ETSI audit statements don't _say_ this, or is the problem that ETSI audits don't _do_ this? It seems to me the problem is the latter - i.e. it's not a problem with correctly describing what was done, it's a problem with what was actually done (or not done). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ETSI audits not listing audit periods
Hi Arno, On 31/10/17 08:46, Arno Fiedler wrote: > there is a problem with the auditor qualification and the national > accreditation of some auditing bodies. Can you help us understand what about the discussion so far leads you to that conclusion? It seems to me that the problem being raised is with the very nature of ETSI audits, not with the qualifications of the auditor or with national accreditation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 18/10/17 13:49, Gervase Markham wrote: > Apple have confirmed that their list is complete and correct. As have Google. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT November 2017 CA Communication
On 27/10/17 00:23, Kathleen Wilson wrote: > Looking forward to further discussion about which errata should be allowed. Those are the correct two errata. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 25/10/17 12:15, Kai Engert wrote: > Will these changes be implemented in the ESR 59.x releases, which will > be released in parallel to the above releases? That's a really good question. I am told that the code implementing the console warning is going to be there before ESR branches, so we should expect the ESR to carry that. JC suggests we should plan to uplift the disablement patch (which may not be simply a root store change) at one of the planned ESR dot releases. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposed policy change: require private pre-notification of 3rd party subCAs
Hi Doug, On 24/10/17 16:43, Doug Beattie wrote: > I assume this applies equally to cross signing, Yes. > but not to "Vanity" CAs that are set up and run by the CA on behalf of a > customer. If you have physical control of the intermediate and control of issuance, it doesn't apply. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Proposed policy change: require private pre-notification of 3rd party subCAs
One of the ways in which the number of organizations trusted to issue for the WebPKI is extended is by an existing CA bestowing the power of issuance upon a third party in the form of control of a non-technically-constrained subCA. Examples of such are the Google and Apple subCAs under GeoTrust, but there are others. Adding new organizations to the list of those trusted is a big deal, and currently Mozilla has little pre-insight into and not much control over this process. CAs may choose to do this for whoever they like, the CA then bears primary responsibility for managing that customer, and as long as they are able to file clean audits, things proceed as normal. Mozilla is considering a policy change whereby we require private pre-notification of such delegations (or renewals of such delegations). We would not undertake to necessarily do anything with such notifications, but lack of action should not be considered permissive in an estoppel sense. We would reserve the right to object either pre- or post-issuance of the intermediate. (Once the intermediate is issued, of course, the CA has seven days to put it in CCADB, and then the relationship would probably become known unless the fields in the cert were misleading.) This may not be where we finally want to get to in terms of regulating such delegations of trust, but it is a small step which brings a bit more transparency while acknowledging the limited capacity of our team for additional tasks. Comments are welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16/10/17 18:32, Gervase Markham wrote: > Here is Mozilla’s planned timeline for the graduated distrust of > Symantec roots (subject to change): This is now https://bugzilla.mozilla.org/show_bug.cgi?id=1409257 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 17/10/17 10:01, Gervase Markham wrote: > Here's an informal list created by me examining the CCADB. Note that the > CCADB links won't work for anyone except Root Store operators. Apple have confirmed that their list is complete and correct. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 17/10/17 15:50, Ryan Sleevi wrote: > That doesn't seem to line up with the discussion in > https://groups.google.com/d/topic/mozilla.dev.security.policy/_EnH2IeuZtw/discussion > to date. Do you have any additional information to share? > > Note that the path you just described is the one that poses non-trivial > risk to the ecosystem, from an interoperability standpoint, and thus may > not be desirable. This seems to be because I'm not following closely enough. The exact design of complex PKIs is not my area :-) I'm sure the people who are experts will work it all out. But yes, in general, the point of the managed CAs is that they will continue to be trusted, somehow, for some additional period of time. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16/10/17 20:22, Peter Bowen wrote: > Will the new managed CAs, which will operated by DigiCert under > CP/CPS/Audit independent from the current Symantec ones, also be > included on the list of subCAs that will continue to function? AIUI we are still working out the exact configuration of the new PKI but my understanding is that the new managed CAs will be issued by DigiCert roots and cross-signed by old Symantec roots. Therefore, they will be trusted in Firefox using a chain up to the DigiCert roots. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16/10/17 20:19, Daniel Cater wrote: > Could we have a list of the subCAs that are being considered for exemption > for the distrust? Here's an informal list created by me examining the CCADB. Note that the CCADB links won't work for anyone except Root Store operators. GeoTrust Global CA | |_ Google Internet Authority G2 (2017-05-22 -> 2018-12-31) | https://ccadb.my.salesforce.com/0011J17aa6MQAQ | https://crt.sh/?id=142951186 | |_ Google Internet Authority G2 (2015-04-01 -> 2017-12-31) https://ccadb.my.salesforce.com/001o00utwbKAAQ https://crt.sh/?id=23635000 GeoTrust Global CA | |_ Apple IST CA 2 - G1 | https://ccadb.my.salesforce.com/001o00p4ScGAAU | https://crt.sh/?id=5250464 | |_ Apple IST CA 5 - G1 https://ccadb.my.salesforce.com/001o00p4ScnAAE https://crt.sh/?id=12716200 GeoTrust Primary Certification Authority - G2 | |_ Apple IST CA 4 - G1 | https://ccadb.my.salesforce.com/001o00p4ScIAAU | https://crt.sh/?id=19602712 | |_ Apple IST CA 7 - G1 | https://ccadb.my.salesforce.com/001o00p4ScIAAU | https://crt.sh/?id=19602724 | |_ Apple IST CA 8 - G1 https://ccadb.my.salesforce.com/001o00qRJHFAA4 https://crt.sh/?id=21760447 GeoTrust Primary Certification Authority - G3 | |_ Apple IST CA 3 - G1 | https://ccadb.my.salesforce.com/001o00p4SciAAE | https://crt.sh/?id=19602706 | |_ Apple IST CA 6 - G1 https://ccadb.my.salesforce.com/001o00p4ScoAAE https://crt.sh/?id=19602741 I will get Google and Apple to validate this data. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Mozilla’s Plan for Symantec Roots
As per previous discussions and https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was reached among multiple browser makers for a graduated distrust of Symantec roots. Here is Mozilla’s planned timeline for the graduated distrust of Symantec roots (subject to change): * January 2018 (Firefox 58): Notices in the Developer Console will warn about Symantec certificates issued before 2016-06-01, to encourage site owners to migrate their TLS certs. * May 2018 (Firefox 60): Websites will show an untrusted connection error if they have a TLS cert issued before 2016-06-01 that chains up to a Symantec root. * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with caveats described below. Mozilla’s release calendar is here: https://wiki.mozilla.org/RapidRelease/Calendar However, there are some subCAs of the Symantec roots that are independently operated by companies whose operations have not been called into question, and they will experience significant hardship if we do not provide a longer transition period for them. For both technical and non-technical reasons, a year is an extremely unrealistic timeframe for these subCAs to transition to having their certificates cross-signed by another CA. For example, the subCA may have implemented a host of pinning solutions in their products that would fail with non-Symantec-chaining certificates, or the subCA may have large numbers of devices that would need to be tested for interoperability with any potential future vendor. And, of course contractual negotiations may take a significant amount of time. The subCAs that we know of that fall into this category belong to Google and Apple. If there are any other subCAs that fall into this category, please let us know immediately. Google has one such subCA; Apple has seven. There are two ways that we can provide a smoother transition for these subCAs. Option 1) Temporarily treat these subCAs as directly-included trust-anchors. Mozilla prefers *not* to take this approach, because even if clearly explained up front that it is a temporary solution with deadlines, it would be very easy for people to start treating such a subCA as a regular trust anchor, and thereby have that subCA become a de facto included CA. Additionally, it could become very complicated to remove such subCAs in the future, especially if they have not performed the recommended transitions. Option 2) Add code to Firefox to disable the root such that only certain subCAs will continue to function. So, the final dis-trust of Symantec roots may actually involve letting one or two of the root certs remain in Mozilla’s trust store, but having special code to distrust all but specified subCAs. We would document the information here: https://wiki.mozilla.org/CA/Additional_Trust_Changes And Mozilla would add tooling to the CCADB to track these special subCAs to ensure proper CP/CPS/audits until they have been migrated and disabled, and the root certs removed. Mozilla will need to also follow up with these subCAs to ensure they are moving away from these root certificates and are getting cross-signed by more than one CA in order to avoid repeating this situation. According to option 2 and the plan listed above, here is how the currently-included Symantec root certs will be treated in Firefox 63: = Symantec roots to be disabled via code, *not* removed from NSS = GeoTrust Global CA GeoTrust Primary Certification Authority - G2 GeoTrust Primary Certification Authority - G3 = Symantec roots that will be fully removed from NSS = GeoTrust Primary Certification Authority GeoTrust Universal CA GeoTrust Universal CA 2 Symantec Class 1 Public Primary Certification Authority - G4 Symantec Class 1 Public Primary Certification Authority - G6 Symantec Class 2 Public Primary Certification Authority - G4 Symantec Class 2 Public Primary Certification Authority - G6 thawte Primary Root CA thawte Primary Root CA - G2 thawte Primary Root CA - G3 VeriSign Class 1 Public PCA - G3 VeriSign Class 2 Public PCA - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G4 VeriSign Class 3 Public Primary Certification Authority - G5 VeriSign Universal Root Certification Authority As always, we appreciate your thoughtful and constructive feedback on this. Gerv [0] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Mozilla’s Plan for Symantec Roots
As per previous discussions and https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was reached among multiple browser makers for a graduated distrust of Symantec roots. Here is Mozilla’s planned timeline for the graduated distrust of Symantec roots (subject to change): * January 2018 (Firefox 58): Notices in the Developer Console will warn about Symantec certificates issued before 2016-06-01, to encourage site owners to migrate their TLS certs. * May 2018 (Firefox 60): Websites will show an untrusted connection error if they have a TLS cert issued before 2016-06-01 that chains up to a Symantec root. * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with caveats described below. Mozilla’s release calendar is here: https://wiki.mozilla.org/RapidRelease/Calendar However, there are some subCAs of the Symantec roots that are independently operated by companies whose operations have not been called into question, and they will experience significant hardship if we do not provide a longer transition period for them. For both technical and non-technical reasons, a year is an extremely unrealistic timeframe for these subCAs to transition to having their certificates cross-signed by another CA. For example, the subCA may have implemented a host of pinning solutions in their products that would fail with non-Symantec-chaining certificates, or the subCA may have large numbers of devices that would need to be tested for interoperability with any potential future vendor. And, of course contractual negotiations may take a significant amount of time. The subCAs that we know of that fall into this category belong to Google and Apple. If there are any other subCAs that fall into this category, please let us know immediately. Google has one such subCA; Apple has seven. There are two ways that we can provide a smoother transition for these subCAs. Option 1) Temporarily treat these subCAs as directly-included trust-anchors. Mozilla prefers *not* to take this approach, because even if clearly explained up front that it is a temporary solution with deadlines, it would be very easy for people to start treating such a subCA as a regular trust anchor, and thereby have that subCA become a de facto included CA. Additionally, it could become very complicated to remove such subCAs in the future, especially if they have not performed the recommended transitions. Option 2) Add code to Firefox to disable the root such that only certain subCAs will continue to function. So, the final dis-trust of Symantec roots may actually involve letting one or two of the root certs remain in Mozilla’s trust store, but having special code to distrust all but specified subCAs. We would document the information here: https://wiki.mozilla.org/CA/Additional_Trust_Changes And Mozilla would add tooling to the CCADB to track these special subCAs to ensure proper CP/CPS/audits until they have been migrated and disabled, and the root certs removed. Mozilla will need to also follow up with these subCAs to ensure they are moving away from these root certificates and are getting cross-signed by more than one CA in order to avoid repeating this situation. According to option 2 and the plan listed above, here is how the currently-included Symantec root certs will be treated in Firefox 63: = Symantec roots to be disabled via code, *not* removed from NSS = GeoTrust Global CA GeoTrust Primary Certification Authority - G2 GeoTrust Primary Certification Authority - G3 = Symantec roots that will be fully removed from NSS = GeoTrust Primary Certification Authority GeoTrust Universal CA GeoTrust Universal CA 2 Symantec Class 1 Public Primary Certification Authority - G4 Symantec Class 1 Public Primary Certification Authority - G6 Symantec Class 2 Public Primary Certification Authority - G4 Symantec Class 2 Public Primary Certification Authority - G6 thawte Primary Root CA thawte Primary Root CA - G2 thawte Primary Root CA - G3 VeriSign Class 1 Public PCA - G3 VeriSign Class 2 Public PCA - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G4 VeriSign Class 3 Public Primary Certification Authority - G5 VeriSign Universal Root Certification Authority As always, we appreciate your thoughtful and constructive feedback on this. Gerv [0] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposed change to CA contact policy
On 11/10/17 11:50, Gervase Markham wrote: > Kathleen now says she would prefer to email the Primary POCs and CC the > email aliases. Handily, this allows for what you suggest. So consider > the proposal changed to that. Or rather, email the primary POCs and CC the first email alias. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
On 13/10/17 15:41, Gervase Markham wrote: > Er, we should fix that... Well, actually it's scoped as being inside the original EV cert request, so there's probably no harm in practice. If any CAB Forum member wants to fix this small error, great, but I've got too many other ballot ideas to juggle. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
On 13/10/17 06:01, Peter Bowen wrote: > This is taken directly from the EV Guidelines section 14.2.2. The > EVGs don't use the PSL, they specify third or higher. Er, we should fix that... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposed change to CA contact policy
On 09/10/17 18:04, Matthew Hardeman wrote: > Echoing Mr. Lamb's concern, I would think that defining two > "important notice role/mailing list recipient addresses" and always > sending important notices to both. This would allow for a mailing > list on CA internal infrastructure as well as one on external > infrastructure. Kathleen now says she would prefer to email the Primary POCs and CC the email aliases. Handily, this allows for what you suggest. So consider the proposal changed to that. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Proposed change to CA contact policy
The CCADB stores a couple of different types of "contact" records: * Primary POC (1 or more): someone who is "authorized to speak for and to bind the CA that they represent." * POC (0 or more): Another contact at that CA. * Email Alias (1 or 2): defined as "more likely to continue working as personnel change". All are per-organization values, and I don't believe any of them are published. However, this then leads to a question about which contacts should be used in what circumstances. The Common CCADB Policy says: "Notification of security and audit-related issues will be emailed to all POCs and the email aliases; CAs are advised to supply sufficient POCs that will enable them to respond to an issue promptly." This is a bit of an administrative pain. The proposal is to change things to put the burden of ensuring the appropriate distribution of messages on to the CA. In future, we would just email the first email alias; CAs are responsible for making sure that value is a mailing list which goes to all appropriate parties or systems necessary to provide a timely response. Any objections? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report format
On 29/09/17 20:08, Jakob Bohm wrote: > 1. Title should also reflect that this is now about various kinds of > incidents. The page is now called: https://wiki.mozilla.org/CA/Responding_To_An_Incident I've also made the other changes. Thank you for your feedback. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Issuing and using SHA-1 OCSP signing certificates
On 06/10/17 19:41, Doug Beattie wrote: > We could provide you with the non-SSL SHA-1 CAs and have them added to OneCRL > as long as we're sure that would not impact their use for client > authentication and secure email. Would that suffice? Yes. File a Bugzilla bug. While we don't have a mandated timescale for this, please migrate new issuance to appropriately-constrained intermediates if you have not done so already. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Issuing and using SHA-1 OCSP signing certificates
On 04/10/17 23:38, Nick Lamb wrote: > However if I understand the situation correctly, this situation is > already very low risk anyway with no reasonable expectation that it > could be exploited against a competent SSL/TLS client which for some > reason still accepts SHA1 and of course no risk for e.g. modern > Firefox which doesn't accepts SHA1 anyway. If I haven't understood > (please anyone jump in) then my assessment may be utterly wrong. Of course, this is an argument for ceasing to regulate SHA-1 issuance at all, because no modern browser accepts it, so why bother? But I don't think we are quite ready to go there; it does have the useful secondary effect of going some way to force obsolete software (like old XP) off the Internet. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On 05/10/17 20:00, Inigo Barreira wrote: > Has this been asked ever? Has any other CA published it? It´s just to know. > And, is there a "default" scope for this kind of security audits? Well, you indicated your willingness to publish them in an email to me, if I remember correctly. And it would allow others to assess your claim that the code is not bad, and is secure. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On 05/10/17 15:32, Inigo Barreira wrote: > I know this reply is not related to the email thread but wouldn´t like to > leave the feeling that the code we are using is bad, or not secure, etc. Perhaps now might be a good time to publish the security audits that were done on the code, then? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On 05/10/17 05:57, Kathleen Wilson wrote: > Bug Filed regarding PROCERT Action Items: > https://bugzilla.mozilla.org/show_bug.cgi?id=1405862 Hi Kathleen, I know you have already filed the bug, but I think that perhaps the list of action items might need to be a bit more detailed and/or rigorous than it is at the moment. For example, I think there is wisdom in what Ryan says about setting an amount of time before a company can re-apply. In the case of StartCom we did not set such a time, because I had thought they might do what I recommended, which was to switch back from the new WoSign infra that we didn't trust to the original StartCom infra, which we did. However, they instead chose to implement new infra from scratch and rushed it, with the result being the use of PHP, the use of coders without sufficient training in security, and some terrible code written under extreme time pressure driven by commercial considerations. We did give WoSign a time limit of 1 year, although it seems that they (now called WoTrus) have not yet applied for re-inclusion. So I think it would be appropriate for us to set a minimum period before PROCERT can re-apply, and that it be longer than 1 year. In addition, we do need to address the question of how we can ascertain that the organization has acquired the technical competence and management rigour which seems to be lacking. I know you have placed some audit requirements in there, but I do think we need to discuss whether those will provide a sufficient guarantee and, if not, if there's anything that could. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Issuing and using SHA-1 OCSP signing certificates
On 03/10/17 18:35, Doug Beattie wrote: > The specific issue is that these client certificate CAs don't have > the EKU extension even though we have no intent of issuing SSL > certificates (they are WT audited and verified to not issue any SSL > certificates per the BRs). Would it be an acceptable solution to add these intermediates to OneCRL? > Is it permissible to continue issuing SHA-1 OCSP signing certificates > for these existing legacy non-SSL CAs so we may continue providing > revocation services using algorithms they support until all > certificates under the CAs expire? This would be no later than the > end of 2020. Can anyone see any problems with an answer to Doug which says that he may do this once the intermediates are in OneCRL? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal -- Specify audit criteria according to trust bit
On 29/09/17 13:21, Peter Bachman wrote: > Can I have a pointer to the current up to date discussion on the S/MIME trust > bit? What sort of discussion? Mozilla's root store still includes an S/MIME trust bit and we have no plans to remove it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA reporting support and tests?
On 26/09/17 00:03, Andrew wrote: > is that the reports should only be sent in a situation where a > certificate _would_ have been issued if not for the CAA records. I'd say that's right. I'd think that by far the more common use case would be internal policy enforcement at a company rather than detecting a 3rd party attacker. And given that it's often just "send an email", one hopes the iodef might not be too onerous for CAs to implement. I believe we scoped it down to only having to support http: and mailto:. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On 26/09/17 03:17, Ryan Sleevi wrote: > update in a year, are arguably outside of the scope of ‘reasonable’ use > cases - the ecosystem itself has shown itself to change on at least that > frequency. Is "1 year" not a relatively common (for some value of "common") setting for HPKP timeouts for sites which think they have now mastered HPKP? Does anyone have stats on HPKP prevalence and duration distribution? Ideally combined with whether the longer time periods are pinning to roots, intermediates or EE certs? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT decision
On 22/09/17 00:33, Andrew wrote:> Will there be any sort of deprecation period for PROCERT certificates > as with StartCom/Wosign & Symantec? Or is PROCERT small enough that > you believe it's feasible to just immediately distrust them without > any significant negative impact on the overall web ecosystem? Kathleen has stated her current plan is to roll this change into the October batch of root changes, which will ship with Firefox 58. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
On 20/09/17 03:49, userwithuid wrote: >> I agree, Gerv's remarks are a bit confusing with respect to the concern. Ryan is polite. :-) > Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part > then and should probably be acknowledged as such, @Gerv. Yes, I acknowledge that this point was confusing; I should have said something more like this: >> However, there is a criticism to be landed here - and that's using the same >> name/keypair for multiple intermediates and revoking one/some of them. This >> creates all sorts of compatibility problems in the ecosystem, and is thus >> unwise practice. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert mis-issuance report: rekeyed certificates
This is https://bugzilla.mozilla.org/show_bug.cgi?id=1401407 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On 27/09/17 18:54, Matthew Hardeman wrote: > In the case of StartCom, I can not help but feel that they are being > held to an especially high standard (higher than other prior adds to > the program) in this new PKI because of who they are -- despite the > fact that management and day-to-day decisions are a completely > different team. > > Where I am headed with this is a concern that perhaps no amount of > technical remediation can really get these entities back in the > graces of the community. I don't know if it's quite as absolute as that, but recent incidents have caused me to ponder somewhat on the nature of trust. The root program is all about trust, and trust is not something which can be encoded in audits, checkboxes and rules. This will always be a tension at the heart of our root program - we are trying to be as objective as we can about something which is ultimately subjective. The nature of trust is that it's harder to regain than it is to gain in the first place. Just ask someone who's been the victim of adultery - or someone who is a now-repentant adulterer. Rightly or wrongly, people get a first chance, but it's tough to get a second. I think you are right when you conclude that this is just the way of things, and we should accept it rather than kick against it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report format
On 22/09/17 00:12, Ryan Sleevi wrote: > Based on the number of reports reviewed recently, I suspect we've got > opportunities for improvement, but I'm not quite sure yet what the concrete > suggestions on that should look like. A few thoughts below: Here's a set of changes which attempt to capture some of what you are requesting. Further input, from you or others, is welcome. https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_A_Misissuance&diff=1181405&oldid=1179230 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
PROCERT decision
The CA Certificates module owner and peers have come to a decision regarding our investigations into the activities of the CA "PROCERT". A large number of issues were raised regarding the operations and practices of this CA: https://wiki.mozilla.org/CA:PROCERT_Issues Considering them, it seems clear to us that PROCERT have not been, and continue not to be, adequately aware of the requirements placed upon them by various RFCs, the CA/Browser Forum's Baseline Requirements, and Mozilla Root Store Policy. They have not demonstrated sufficient control of their issuance pipeline or sufficient checking of the results to avoid regularly creating certificates which violate the requirements of one or more of those documents. PROCERT have also made assurances to us, via responses to CA Communications, that certain things were true which are manifestly not so (e.g. that they were using properly-randomized serial numbers). In addition, PROCERT's response to these issues was inadequate. While they revoked (most, but not all, of) the certificates which were flagged as problematic, their written responses have been limited in number and are very superficial. In some cases, it is clear that they have not understood the issue that was raised. They have not, to our knowledge, performed any root cause analysis which might allow us to have some confidence that problems of this or a similar nature will not recur. We have very little insight into their systems and what, if any, safeguards they have in place. It seems that PROCERT's belief is that revocation is an adequate remedy for all of the problems listed. We disagree. Therefore, we feel we can no longer trust PROCERT, and plan to proceed with removing their "PSPProcert" certificate from our root program and root store. Kathleen Wilson Gervase Markham Ryan Sleevi ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incident Report format
It seems like the list of topics to cover on the Responding to a Misissuance page: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report has become a de facto template for incident reports. We've now had quite a few CAs use this outline to respond to issues. If people (CAs or others) have feedback on how this template could be improved, that would be a fine thing. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
Additionally, 13 days ago it was reported to VISA that their OCSP responder was misconfigured to return "good" responses for non-existent certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1398261 As far as I can see, this is the case for their end-entity certificates, not just some roots or intermediates. Two weeks later, they have not yet provided any response. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy