Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wildcard certs present a level of risk that is different (higher?) than > for other end-entity certs. The risk as I see it is two-fold: > > 1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is > no clear way to extrapolate a successful validation for one domain into a > plethora of FQDN's in a way that works for all scenarios. So the risk in > this sense is that the issuer might allow a cert requester to > over-subscribe a given domain's name space. > See the discussion in the CA Browser Forum regarding 3.2.2.4 and "Domain Namespace". There's an arguable interpretation that allows for a single domain validation and an unlimited number of certificates for an arbitrary number of subdomains. > > 2) Abuse: Once the wildcard cert has been issued there is no way to check > that the host (or FQDN) to which I'm connecting is a legitimate part of the > broader domain or if it has been taken over for nefarious purposes. This is > in contrast to the non-wildcard case wherein I know it's a legitimate part > because I see the FQDN listed explicitly in the SAN field. So the risk in > this sense is to the relying party who is less able to protect himself or > herself from connecting to bad servers. > I'm not sure I understand this point. Of course it's legitimate - as it's part of the subdomain. Could you expand further what you see as wrong here? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On Tue, Apr 25, 2017 at 12:58 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Look at my two examples of past acquisitions. As far as I remember, in > neither case was the purchasing security company previously a trusted > CA, and they took over practically the whole operation with no initial > changes besides a name change. > Yes. And that worked out badly for security. Put differently, it sounds like you're suggesting it's more desirable to 'keep everything the same', when it is fairly consistent that only by changing and integrating is progress made and security achieved. Both VeriSign and Verizon are proof of the bad and the good. > Another variant of this scenario is when a CA restructures its formal > ownership structure, such as inserting or removing one or more levels > of companies between the ultimate owners and the CA operations > activity. In many cases this would technically be an acquisition by a > new company that isn't a CA itself (as the acquiring company would > often be an empty shell). One example would be the recent creation of > GTS from part of Google Inc, since GTS was a new company with no past > CA activity, while the acquired Google division had a past as a SubCA > and a recently acquired root cert. I'm afraid I've yet again lost the point you're trying to make. Perhaps it would help if I stated it differently: Peter's original suggestion was "The purchaser has not been in compliance with Mozilla policies for more than 12 months but will do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies." This would cover the situation of formal restructuring - by providing a statement of continued commitment. This would cover the situation of merging/integration - by providing a statement of continued commitment. This would cover the situation of independent operation - by providing a statement of continued commitment. In response to this, you suggested "The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as will be detailed during such negotiations. This, or some other wording, would be for a complete purchase of the business rather than a merge into an existing CA," The first sentence has generally resulted in more harm than good. Combined with the second sentence, it appears you believe this would be the desirable outcome - moreso than a statement of continued commitment. I'm asking you what problem you were trying to solve, and how you sought to achieve that, because it would seem that your proposal, as an endorsement for 'independent' operation in such acquisitions, is generally more harmful than helpful to the Web PKI security. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs. The risk as I see it is two-fold:1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no clear way to extrapolate a successful validation for one domain into a plethora of FQDN's in a way that works for all scenarios. So the risk in this sense is that the issuer might allow a cert requester to over-subscribe a given domain's name space.2) Abuse: Once the wildcard cert has been issued there is no way to check that the host (or FQDN) to which I'm connecting is a legitimate part of the broader domain or if it has been taken over for nefarious purposes. This is in contrast to the non-wildcard case wherein I know it's a legitimate part because I see the FQDN listed explicitly in the SAN field. So the risk in this sense is to the relying party who is less able to protect himself or herself from connecting to bad servers.The use of "problematic" to describe wildcard certs is perhaps misleading. Perhaps the wildcard certs themselves are not problematic but trying to manage or mitigate the risk they pose is. Either way, I don't think it would be wise to remove this from the problematic practices list. From: Gervase Markham via dev-security-policySent: Monday, April 24, 2017 4:16 AMOn 21/04/17 12:09, Nick Lamb wrote:> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate> for verifying that the applicant controls the entire domain and thus> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant> controls a web server, it seems quite likely they have neither the> legal authority nor the practical ability to control servers with> other names in that domain. I can see arguments either way for> 3.2.2.4.4, depending on how well email happens to be administrated in> a particular organisation.So your concern is that a subset of the 10 Blessed Methods might not besuitable for verifying the level of control necessary to safely issue awildcard cert?If that's true, we should look at it, but I don't see how that'sconnected with saying or not saying on our wiki page that wildcard certsare inherently problematic.So, to analyse: you are saying that demonstrating control overhttp://www.example.com/ and getting a cert for *.www.example.com isshaky? Or demonstrating control of http://example.com/ and getting acert for *.example.com? Or something else?Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On Monday, April 24, 2017 at 9:58:29 PM UTC-7, Jakob Bohm wrote: > On 25/04/2017 05:04, Ryan Sleevi wrote: > > On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 25/04/2017 03:10, Peter Kurrasch wrote: > >> > >>> Fair enough. I propose the following for consideration: > >>> > >>> Prior to transferring ownership of a root cert contained in the trusted > >>> store (either on an individual root basis or as part of a company > >>> acquisition), a public attestation must be given as to the intended > >>> management of the root upon completion of the transfer. "Intention" must > >>> be one of the following: > >>> > >>> A) The purchaser has been in compliance with Mozilla policies for more > >>> than 12 months and will continue to administer (operate? manage?) the > >>> root in accordance with those policies. > >>> > >>> B) The purchaser has not been in compliance with Mozilla policies for > >>> more than 12 months but will do so before the transfer takes place. The > >>> purchaser will then continue to administer/operate/manage the root in > >>> accordance with Mozilla policies. > >>> > >>> How about: > >> > >> B2) The purchaser is not part of the Mozilla root program and has not > >> been so in the recent past, but intends to continue the program > >> membership held by the seller. The purchaser intends to complete > >> approval negotiations with the Mozilla root program before the transfer > >> takes place. The purchaser intends to retain most of the expertise, > >> personnel, equipment etc. involved in the operation of the CA, as will > >> be detailed during such negotiations. > >> > >> This, or some other wording, would be for a complete purchase of the > >> business rather than a merge into an existing CA, similar to what > >> happened when Symantec purchased Verisign's original CA business years > >> ago, or (on a much smaller scale) when Nets purchased the TDC's CA > >> business unit and renamed it as DanID. > >> > > > > Why is that desirable? If anything, such acquisitions seem to be more > > harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge > > be useful/desirable? What problems are you attempting to solve? > > > > Look at my two examples of past acquisitions. As far as I remember, in > neither case was the purchasing security company previously a trusted > CA, and they took over practically the whole operation with no initial > changes besides a name change. > > Another variant of this scenario is when a CA restructures its formal > ownership structure, such as inserting or removing one or more levels > of companies between the ultimate owners and the CA operations > activity. In many cases this would technically be an acquisition by a > new company that isn't a CA itself (as the acquiring company would > often be an empty shell). One example would be the recent creation of > GTS from part of Google Inc, since GTS was a new company with no past > CA activity, while the acquired Google division had a past as a SubCA > and a recently acquired root cert. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded Jakob, I would add that in cases where CA organizations are acquired outright and the staff and infrastructure are retained it is often only for a limited period of time. In other words, the acquisition takes place and then after some relatively short period of time we see the acquirer try to: - align operations with other parts of the business, - achieve cost savings, - improve technology, performance, scale and disaster recovery ability. These all tend to result in a reboot of "what was there" prior to the acquisition. In these situations dislocated key staff often finds new roles at another CA or move on to non-ca related roles and sleep better ;) Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 25/04/2017 05:04, Ryan Sleevi wrote: On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a public attestation must be given as to the intended management of the root upon completion of the transfer. "Intention" must be one of the following: A) The purchaser has been in compliance with Mozilla policies for more than 12 months and will continue to administer (operate? manage?) the root in accordance with those policies. B) The purchaser has not been in compliance with Mozilla policies for more than 12 months but will do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies. How about: B2) The purchaser is not part of the Mozilla root program and has not been so in the recent past, but intends to continue the program membership held by the seller. The purchaser intends to complete approval negotiations with the Mozilla root program before the transfer takes place. The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as will be detailed during such negotiations. This, or some other wording, would be for a complete purchase of the business rather than a merge into an existing CA, similar to what happened when Symantec purchased Verisign's original CA business years ago, or (on a much smaller scale) when Nets purchased the TDC's CA business unit and renamed it as DanID. Why is that desirable? If anything, such acquisitions seem to be more harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge be useful/desirable? What problems are you attempting to solve? Look at my two examples of past acquisitions. As far as I remember, in neither case was the purchasing security company previously a trusted CA, and they took over practically the whole operation with no initial changes besides a name change. Another variant of this scenario is when a CA restructures its formal ownership structure, such as inserting or removing one or more levels of companies between the ultimate owners and the CA operations activity. In many cases this would technically be an acquisition by a new company that isn't a CA itself (as the acquiring company would often be an empty shell). One example would be the recent creation of GTS from part of Google Inc, since GTS was a new company with no past CA activity, while the acquired Google division had a past as a SubCA and a recently acquired root cert. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On Monday, April 24, 2017 at 8:02:15 PM UTC-7, Peter Kurrasch wrote: > I see what you're saying and there should be some consideration for that > scenario. If the acquiring company will keep all the same infrastructure and > staff and if decision making authority will remain with that staff, then I > think it's reasonable to make that accommodation. > > > Using a word like "all" could be going too far but at the moment I'm not sure > how to strike a softer tone and still have something that is precise and > enforceable. > Peter, Sending this from my personal account (my work laptop isn't handy) so will avoid discussions of anything related to GTS but I wanted to share my perspective as someone who has done built a number of CAs as well as participated in and led several transfers. Your text seems to suggest that there is something inherently good about keeping the current staff and infrastructure. My experience has been that is not necessarily the case. To be clear I understand your position, though I disagree, that being you see there is a value in one organization having all the certificates that bear the same brand. I don't wish to re-debate that with you I just wanted to provide some examples of where partial transfers have provided the Internet at large value. The most recent example of this is DigiCert's acquisition of the Verizon assets. In this case, the existing staff and business leadership demonstrated a continual inability to in accordance with the requirements. DigiCert stepped up to provide the needed adult supervision and paying for the right to do so. While it is true that in this case the keys were being acquired by a member of a root program I think the most important things are that an organization with the means, skills, and vested interest stepped up. There have also been several (largely) non-public examples where organizations with tons of means loss all interest and the keys were left in the hands of the unqualified and uninterested audits don't show this. Thankfully in both of these cases, I think largely the right thing happened. In one case the sr. leadership at the business ultimately decided to destroy the key material once they understood what it could be used for. Of the possible outcomes, I guess it is fair to say that the outcome here was not bad but I have spent a big chunk of my career trying to get the web encrypted and honestly I wish those keys could have been used by a new entrant, maybe Let's Encrypt to make SSL more ubiquitous. This last point material because it took Let's Encrypt nearly two years to find someone to cross them. There are also other cases where CAs were carved up and sold off in bits and the only thing that remained was the keys, none of the staff or other infrastructure was used. These keys also went to other CAs. Anyway, I personally think Mozilla Root Program should be managed with a high order goal of increasing the use of encryption on the web. Root sales and transfers have been a big part of how we have gotten to over 50% of the web being encrypted and I suspect it will continue to be important. In short, I think it would be a shame if we precluded these transfers and instead think it is best to focus on how to make sure the receiving organization proves they can continue to meet the criteria, or like in the case of DigiCert's acquisition, they have a plan to remedy the issues that have been identified. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Conclusions and Next Steps
On Tue, Apr 25, 2017 at 12:14 AM, Ryan Sleevi wrote: > Gerv, > > Is there any update on https://wiki.mozilla.org/ > CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_ > Unconstrained_Intermediates_.28December_2015_-_April_2017.29 ? > > I'm just wanting to understand how this relates to Mozilla's PKI policy > and expectations, and better understand why you struck it. > > - The CP/CPS does not state adherence to the Baseline Requirements. > - The audit was only to "WebTrust Principles and Criteria for CAs v2.0" - > e.g. not BRs > - Seemingly excluded from scope of the audits are the following, for > https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired , on the basis of > Footnote 1 in https://www.symantec.com/content/en/us/about/media/ > repository/Symantec-NFSSP-WTCA_11-30-2016.pdf > - https://crt.sh/?id=19602740 > - https://crt.sh/?id=19602709 > - https://crt.sh/?id=19602733 > - https://crt.sh/?id=19602720 > - https://crt.sh/?id=19602670 > - https://crt.sh/?id=19602679 > - https://crt.sh/?id=19602705 > - https://crt.sh/?id=19602730 > > Of critical relevance: > - If you examine the CPS that was audited, https://www.symantec. > com/content/en/us/about/media/repository/nf-ssp-pki-cps.pdf, it notes in > Appendix A.5 that the profile includes issuing certificates with dNSName > and iPAddress SANs, with the anyExtendedKeyUsage (or the presence of more > specific EKUs) > > - If you examine Symantec's statements on this matter in > https://bugzilla.mozilla.org/attachment.cgi?id=8860216 , they stated > "Under the Non-Federal SSP program, they are used to issue certificates for > Microsoft Windows domain controllers and IPSec endpoints." . A Windows > Domain controller requires that it have id-kp-serverAuth, with a dNSName > SAN ( https://support.microsoft.com/en-us/help/291010/ > requirements-for-domain-controller-certificates-from-a-third-party-ca ) > I actually missed something in https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 "With the wind-down of the SSL/TLS RA program, all authentication and issuance of certificates chaining to Class 3 CAs is done by Symantec; Google and Apple in the case of the GeoRoot sub-CAs; and customers of the Non-Federal SSP program (in this case used to issue certificates for Microsoft Windows domain controllers and IPSec endpoints). " This would imply that customers of the NF SSP program can direct and perform RA duties for the issuance of domain controller certificates, which have the full capability of TLS server certificates, as directed above. This would seem consistent with the audit findings in https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf which states "Symantec makes use of external registration authorities for specific subscriber registration activities for the Symantec Non-Federal SSP - Customer Specific CAs and Symantec Healthcare CA ... Our examination did not extend to the controls exercised by these external registration authorities." So the audit, the CPS, and Symantec's own statements seem to indicate that external RAs had the capability of issuing domain controller certificates, which would minimally include id-kp-serverAuth, id-kp-clientAuth, and dNSName SANs, from an intermediate that was and is enabled for TLS server authentication at the request of VeriSign ( https://bugzilla.mozilla.org/show_bug.cgi?id=515470 ) and as maintained by Symantec. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Conclusions and Next Steps
Gerv, Is there any update on https://wiki.mozilla.org/CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_Unconstrained_Intermediates_.28December_2015_-_April_2017.29 ? I'm just wanting to understand how this relates to Mozilla's PKI policy and expectations, and better understand why you struck it. - The CP/CPS does not state adherence to the Baseline Requirements. - The audit was only to "WebTrust Principles and Criteria for CAs v2.0" - e.g. not BRs - Seemingly excluded from scope of the audits are the following, for https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired , on the basis of Footnote 1 in https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf - https://crt.sh/?id=19602740 - https://crt.sh/?id=19602709 - https://crt.sh/?id=19602733 - https://crt.sh/?id=19602720 - https://crt.sh/?id=19602670 - https://crt.sh/?id=19602679 - https://crt.sh/?id=19602705 - https://crt.sh/?id=19602730 Of critical relevance: - If you examine the CPS that was audited, https://www.symantec.com/content/en/us/about/media/repository/nf-ssp-pki-cps.pdf, it notes in Appendix A.5 that the profile includes issuing certificates with dNSName and iPAddress SANs, with the anyExtendedKeyUsage (or the presence of more specific EKUs) - If you examine Symantec's statements on this matter in https://bugzilla.mozilla.org/attachment.cgi?id=8860216 , they stated "Under the Non-Federal SSP program, they are used to issue certificates for Microsoft Windows domain controllers and IPSec endpoints." . A Windows Domain controller requires that it have id-kp-serverAuth, with a dNSName SAN ( https://support.microsoft.com/en-us/help/291010/requirements-for-domain-controller-certificates-from-a-third-party-ca ) Thus, there is every indication that Symantec has issued certificates used for SSL/TLS under these intermediates and failed to maintain the appropriate audits, as required by Mozilla Policy. Perhaps it might be useful to clarify, given that DigiCert and Verizon have, since January, been operating under a different set of advice from Mozilla: For a CA not "intended" to issue SSL/TLS certificates, but is technically capable of doing so, and merely has not, what audits does Mozilla expect around this? Further, does Mozilla expect a sampling audit of 3% or a full audit of 100% with respect to whatever attestations are made regarding the non-issuance of TLS certificates? For your reference, this was https://bugzilla.mozilla.org/show_bug.cgi?id=1335253 , and you can find the thread titled "RE: Audit of Belgian subordinates" dated Jan 6 to several of the CA peers, including yourself. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 25/04/2017 03:10, Peter Kurrasch wrote: > >> Fair enough. I propose the following for consideration: >> >> Prior to transferring ownership of a root cert contained in the trusted >> store (either on an individual root basis or as part of a company >> acquisition), a public attestation must be given as to the intended >> management of the root upon completion of the transfer. "Intention" must >> be one of the following: >> >> A) The purchaser has been in compliance with Mozilla policies for more >> than 12 months and will continue to administer (operate? manage?) the >> root in accordance with those policies. >> >> B) The purchaser has not been in compliance with Mozilla policies for >> more than 12 months but will do so before the transfer takes place. The >> purchaser will then continue to administer/operate/manage the root in >> accordance with Mozilla policies. >> >> How about: > > B2) The purchaser is not part of the Mozilla root program and has not > been so in the recent past, but intends to continue the program > membership held by the seller. The purchaser intends to complete > approval negotiations with the Mozilla root program before the transfer > takes place. The purchaser intends to retain most of the expertise, > personnel, equipment etc. involved in the operation of the CA, as will > be detailed during such negotiations. > > This, or some other wording, would be for a complete purchase of the > business rather than a merge into an existing CA, similar to what > happened when Symantec purchased Verisign's original CA business years > ago, or (on a much smaller scale) when Nets purchased the TDC's CA > business unit and renamed it as DanID. > Why is that desirable? If anything, such acquisitions seem to be more harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge be useful/desirable? What problems are you attempting to solve? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
I see what you're saying and there should be some consideration for that scenario. If the acquiring company will keep all the same infrastructure and staff and if decision making authority will remain with that staff, then I think it's reasonable to make that accommodation.Using a word like "all" could be going too far but at the moment I'm not sure how to strike a softer tone and still have something that is precise and enforceable.From: Jakob Bohm via dev-security-policySent: Monday, April 24, 2017 8:42 PMOn 25/04/2017 03:10, Peter Kurrasch wrote:> Fair enough. I propose the following for consideration:>> Prior to transferring ownership of a root cert contained in the trusted> store (either on an individual root basis or as part of a company> acquisition), a public attestation must be given as to the intended> management of the root upon completion of the transfer. "Intention" must> be one of the following:>> A) The purchaser has been in compliance with Mozilla policies for more> than 12 months and will continue to administer (operate? manage?) the> root in accordance with those policies.>> B) The purchaser has not been in compliance with Mozilla policies for> more than 12 months but will do so before the transfer takes place. The> purchaser will then continue to administer/operate/manage the root in> accordance with Mozilla policies.>How about:B2) The purchaser is not part of the Mozilla root program and has notbeen so in the recent past, but intends to continue the programmembership held by the seller. The purchaser intends to completeapproval negotiations with the Mozilla root program before the transfertakes place. The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as willbe detailed during such negotiations.This, or some other wording, would be for a complete purchase of thebusiness rather than a merge into an existing CA, similar to whathappened when Symantec purchased Verisign's original CA business yearsago, or (on a much smaller scale) when Nets purchased the TDC's CAbusiness unit and renamed it as DanID.> C) The purchaser does not intend to operate the root in accordance with> Mozilla policies. Mozilla should remove trust from the root upon> completion of the transfer. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
On 25/04/2017 03:10, Peter Kurrasch wrote: Fair enough. I propose the following for consideration: Prior to transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a public attestation must be given as to the intended management of the root upon completion of the transfer. "Intention" must be one of the following: A) The purchaser has been in compliance with Mozilla policies for more than 12 months and will continue to administer (operate? manage?) the root in accordance with those policies. B) The purchaser has not been in compliance with Mozilla policies for more than 12 months but will do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies. How about: B2) The purchaser is not part of the Mozilla root program and has not been so in the recent past, but intends to continue the program membership held by the seller. The purchaser intends to complete approval negotiations with the Mozilla root program before the transfer takes place. The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as will be detailed during such negotiations. This, or some other wording, would be for a complete purchase of the business rather than a merge into an existing CA, similar to what happened when Symantec purchased Verisign's original CA business years ago, or (on a much smaller scale) when Nets purchased the TDC's CA business unit and renamed it as DanID. C) The purchaser does not intend to operate the root in accordance with Mozilla policies. Mozilla should remove trust from the root upon completion of the transfer. The wording of the above needs some polish and perhaps clarification. The idea is that the purchaser must be able to demonstrate some level of competence at running a CA--perhaps by first cutting their teeth as a sub-CA? If a organization is "on probation" with Mozilla, I don't think it makes sense to let them assume more control or responsibility for cert issuance so there should be a mechanism to limit that. I also think we should allow for the possibility that someone may legitimately want to remove a cert from the Mozilla program. Given the disruption that such a move can cause, it is much better to learn that up front so that appropriate plans can be made. *From: *Gervase Markham via dev-security-policy *Sent: *Tuesday, April 11, 2017 11:36 AM *To: *mozilla-dev-security-pol...@lists.mozilla.org *Reply To: *Gervase Markham *Subject: *Re: Criticism of Google Re: Google Trust Services roots On 11/04/17 14:05, Peter Kurrasch wrote: Is there room to expand Mozilla policy in regards to ownership issues? Subject to available time (which, as you might guess by the traffic in this group, there's not a lot of right now, given that this is not my only job) there's always room to reconsider policy. But what we need is a clearly-stated and compelling case that changing the way we think about these things would have significant and realisable benefits, and that any downsides are fairly enumerated and balanced against those gains. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Google Re: Google Trust Services roots
Fair enough. I propose the following for consideration:Prior to transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a public attestation must be given as to the intended management of the root upon completion of the transfer. "Intention" must be one of the following:A) The purchaser has been in compliance with Mozilla policies for more than 12 months and will continue to administer (operate? manage?) the root in accordance with those policies.B) The purchaser has not been in compliance with Mozilla policies for more than 12 months but will do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies.C) The purchaser does not intend to operate the root in accordance with Mozilla policies. Mozilla should remove trust from the root upon completion of the transfer.The wording of the above needs some polish and perhaps clarification. The idea is that the purchaser must be able to demonstrate some level of competence at running a CA--perhaps by first cutting their teeth as a sub-CA? If a organization is "on probation" with Mozilla, I don't think it makes sense to let them assume more control or responsibility for cert issuance so there should be a mechanism to limit that.I also think we should allow for the possibility that someone may legitimately want to remove a cert from the Mozilla program. Given the disruption that such a move can cause, it is much better to learn that up front so that appropriate plans can be made.From: Gervase Markham via dev-security-policySent: Tuesday, April 11, 2017 11:36 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 11/04/17 14:05, Peter Kurrasch wrote:> Is there room to expand Mozilla policy in regards to ownership issues?Subject to available time (which, as you might guess by the traffic inthis group, there's not a lot of right now, given that this is not myonly job) there's always room to reconsider policy. But what we need isa clearly-stated and compelling case that changing the way we thinkabout these things would have significant and realisable benefits, andthat any downsides are fairly enumerated and balanced against those gains.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Updating Bugzilla Product/Component groups for CA Program Bugs
All, This is just for informational purposes... I have filed Bug #1359112 to update the Bugzilla Product/Components for the CA Program Bugs. The bugs asks: ~~ Current Product: NSS Current Component Name: CA Certificates change to Product: NSS Component Name: CA Certificate Code Current Product: mozilla.org Current Component Name: CA Certificate Mis-Issuance Change to Product: NSS Component Name: CA Certificate Mis-Issuance Current Product: mozilla.org Current Component Name: CA Certificates Change to Product: NSS Component Name: CA Certificate Root Program ~~ So, the result will be that all CA Program related bugs will be in the NSS Product group in Bugzilla. And the NSS Product group will have the following Components: Build CA Certificate Code CA Certificate Mis-Issuance CA Certificate Root Program Documentation Libraries Test Tools This will impact saved Bugzilla searches regarding CA Program bugs. And wiki pages referring to the Bugzilla Product/Components regarding CA program bugs will need to be updated -- will try to take care of that soon after the change. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT - BR Self Assessments
On Saturday, April 22, 2017 at 5:25:35 AM UTC-7, wangs...@gmail.com wrote: > We have a question about completing the BR self assessment, > is it necessary that all the BRs requirements appear in > relevant sections of the CP/CPS? It is OK if the information is in different sections in the CP/CPS, just be sure to indicate which sections of the CP/CPS the information is in. > Or for some BRs requirements that are not specifically > disclosed in the CP/CPS, CAs can explain their rules and > practices to show that they meet or exceed these requirements? Per section 3.3 Mozilla's CA Certificate Policy: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ "We rely on publicly disclosed documentation (e.g., in a Certificate Policy and Certification Practice Statement) to ascertain that our requirements are met." So, for the most part, the information must be available in publicly disclosed documentation that is available on the CA's website. And in the BR Self Assessment you need to clearly indicate which document and which section of the document shows that your CA meets the BR. There are items, such as the three test websites, that we can verify directly, so those items do not need to be in the CP/CPS documents. When you are doing your BR Self Assessment, if you find that the required information is not currently in your CP/CPS documents, then you may indicate what your CA currently does, how it is currently documented, that the next version of your CP/CPS will contain this information, and when the next version of your CP/CPS will be available. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Extend deadline for April 2017 CA Communication?
I added a note about the extension to May 5 to https://wiki.mozilla.org/CA:Communications#April_2017 Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate issues
On 21/04/2017 21:29, Nick Lamb wrote: On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote: I believe the point was to check the prospective contents of the TBSCertificate *before* CT logging (noting that Ryan Sleevi has been violently insisting that failing to do that shall be punished as harshly as actual misissuance) and *before* certificate signing. I come to this as always as someone focused on prevention of future harm. I can't speak for Ryan but I'm not interested in "punishing" anybody because retribution does not avoid future harm in itself. For example distrust of a CA is not a "punishment" of that CA, but a step taken to protect relying parties from certificates which shouldn't exist. Detecting already bad situations still counts as prevention of future harm, this is because almost always the bad situation might get worse if undetected. This is why we fit smoke alarms - it would be bad if my flat was on fire, but it would be much worse if in the absence of an alarm it simply burned down with me inside it. If some CA comes to m.d.s.policy twice a year with a problem where a certificate was issued that shouldn't have been, but they've cured it and altered their systems so that won't happen again - I can't say I'm ecstatic to see that, but at least they're paying attention. In contrast if they're here twice a year because an independent researcher found a year-old certificate that shouldn't exist, and Gerv has to ask them for comment, then they investigate what went wrong and promise to cure it, I have to say I look on that much less kindly, and I suspect Ryan does too. I wrote this in the context of your previous post about why this prevention code would have the ability to accidentally alter the certificate before it was signed. My point was to explain, in general, why such code is forced to run before signing and in a context where preventing the checking code from altering the certificate has a (small but) non-zero cost, unlike a check done after issuance and/or after CT submission. As for Ryan, I think his own response was quite illustrative. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Announcing TLS Canary 3.0
Hi all, TLS Canary is a tool that finds Firefox SSL regressions. We run the tool on a regular basis, at a minimum post-branch and sporadically during the release cycle. Results of runs are posted to a public web site [1]. We use the canary to gauge impact of proposed changes to our TLS stack, with regard to things such as certificate revocation, security hardening, cipher suites, and other potential compatibility issues. The results can be used to help drive product decisions. Now that the TLS Canary codebase is hosted in a public Mozilla repo [2], we are appealing to interested participants for feedback and contribution. We have lots of Q2 features planned and are always looking for ideas. Thanks, CR and Matt [1] https://tlscanary.mozilla.org [2] https://github.com/mozilla/tls-canary ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Conclusions and Next Steps
On 2017-04-24 11:18, Gervase Markham wrote: On 21/04/17 11:38, Kurt Roeckx wrote: I'm still concerned that they don't seem to have an idea of what software they're all (still) running, and they didn't reply to any question about it. I'm sorry, I don't follow. Can you expand? I confused some of the issues. It was about issue J. The reply (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM) talked about "deprecated, enterprise-only interface" and "historic interface". This seems to imply that either deprecated interfaces don't need to follow the BR requirements or they have no overview of all the software they are still running and so didn't check all of them to be in compliance. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
Hi Blake, On 21/04/17 16:55, blake.mor...@trustis.com wrote: > Following further discussion with, and guidance from Mozilla, it has > been determined that the getset.trustis.com certificate issued in > November 2016 was a mis-issuance. This incident has highlighted an > ambiguity arising from the mismatch of scope between CAB Forum BRs > v1.3 and Mozilla CP v2.3. It is useful to note that the Mozilla CP > v2.4 provides revised wording which represents an improvement in this > regard. Thank you for the update. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Conclusions and Next Steps
On 21/04/17 11:38, Kurt Roeckx wrote: > I'm still concerned that they don't seem to have an idea of what > software they're all (still) running, and they didn't reply to any > question about it. I'm sorry, I don't follow. Can you expand? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On 22/04/17 02:23, Matt Palmer wrote: > Didn't a CA get caught fairly recently issuing certs with sAN:example.com > when the validation was for www.example.com, and got a stern talking to as a > result? I vaguely recall something about that, but not with enough detail > to trawl the archives looking for it. Yes, it was WoSign. https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29 Bug N1. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On 21/04/17 12:09, Nick Lamb wrote: > Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate > for verifying that the applicant controls the entire domain and thus > *.example.com, whereas say 3.2.2.4.6 proves only that the applicant > controls a web server, it seems quite likely they have neither the > legal authority nor the practical ability to control servers with > other names in that domain. I can see arguments either way for > 3.2.2.4.4, depending on how well email happens to be administrated in > a particular organisation. So your concern is that a subset of the 10 Blessed Methods might not be suitable for verifying the level of control necessary to safely issue a wildcard cert? If that's true, we should look at it, but I don't see how that's connected with saying or not saying on our wiki page that wildcard certs are inherently problematic. So, to analyse: you are saying that demonstrating control over http://www.example.com/ and getting a cert for *.www.example.com is shaky? Or demonstrating control of http://example.com/ and getting a cert for *.example.com? Or something else? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
