I think it would be very unreasonable, unfortunately. Such a discussion requires defining what a reseller is - and a whole spectrum exists in which Amazon Certificate Manager, Venafi, Dreamhost, and more (all very different services) could unduly get swept up into such a definition.
Further, I think in a world of automated issuance, it would be even more harmful towards automation, by suggesting more restrictions on who can get certificates and how. I understand the frustration that such resellers exist. I think it highlights failures of the CAs that partner with such resllers to educate them (and their customers) as to best practices. But I think beyond that, restrictions by CAs or censure by browsers will be actively harmful to the ecosystem as a whole, and that is why I push back on such proposals. Is it ideal? No. Should we actively call out insecurity - absolutely. But I hesitate to believe that more can be done without causing more harm than good, sadly. On Mon, Mar 5, 2018 at 9:42 AM Eric Mill <e...@konklone.com> wrote: > I think it probably makes more sense to focus on sensitive key material > than non-sensitive CSRs. > > As a starting point, how reasonable would it be for CAs to question their > resellers, or to disseminate additional language to add to their reseller > agreements to prohibit non-transactional/ephemeral key storage? > > -- Eric > > On Mon, Mar 5, 2018 at 9:15 AM, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Considering that the Baseline Requirements explicitly acknowledge that the >> Applicant may delegate the obtaining of their certificates to a >> third-party >> (Applicant Representative), how would you propose that the applicant's >> agents (which, in a legal sense, is the name for their employees - that >> is, >> those with legal authority to represent the company) and resellers? >> >> What would stop someone from offering a "CSR-as-a-service" in which they >> generate CSRs for users, and then users take that generated CSR to the CA? >> What role are you suggesting that the CA has to play in policing 'how' the >> CSR was generated - since a CSR is-a CSR is-a CSR? >> >> On Mon, Mar 5, 2018 at 8:26 AM, James Burton via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > Currently, resellers are allowed to submit CSRs on behalf of their >> > customers and as we've seen this is open to abuse. Maybe it's time to >> stop >> > this practice and restrict submission of CSRs to CA portals only. >> > >> > On Mon, Mar 5, 2018 at 12:51 PM, okaphone.elektronika--- via >> > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: >> > >> > > On Sunday, 4 March 2018 22:44:26 UTC+1, Paul Kehrer wrote: >> > > > On March 4, 2018 at 5:06:41 PM, Eric Mill via dev-security-policy ( >> > > > dev-security-policy@lists.mozilla.org) wrote: >> > > > >> > > > <snip> >> > > > >> > > > It's also clear from the experience that rules of the road for >> > resellers >> > > > are unclear, and that accountability is limited. It seems possible, >> or >> > > > likely, that other resellers may also be mishandling customer keys >> > > > >> > > > So, what would useful next steps be to improve security and >> > > accountability >> > > > for resellers? >> > > > >> > > > >> > > > As you already suggested an official communication requesting >> > information >> > > > from the CAs about the way their reseller networks manage subscriber >> > key >> > > > material would be a good start. Eventually I think it's likely that >> > > > resellers need to be subject to some limited form of audit (maybe as >> > > > simplistic as a PCI self-assessment questionnaire?). While that >> doesn't >> > > > prevent bad behavior it would generate an evidence trail for >> > termination >> > > of >> > > > relationships with incompetent/malicious actors. >> > > >> > > I'm not sure that that would be reasonable. After all resellers can >> have >> > > resellers, and so on so where would that end? With the end user >> having to >> > > accept a "general license agreement"? And distrusting a reseller could >> > also >> > > be difficult. >> > > >> > > I think it will have to be/remain the responsibility of the CA to >> choose >> > > their reselllers in such a way that "not too many questions are being >> > > asked" about them. >> > > >> > > >> > > > Of course, CAs are likely to be reluctant to share a complete list >> of >> > > their >> > > > resellers since they probably consider that competitive information. >> > So, >> > > it >> > > > would be nice if we could just make it part of the CA's audits... >> > > > >> > > > One way to do that would be that the baseline requirements could be >> > > updated >> > > > to create a section defining requirements placed upon resellers >> > > (especially >> > > > around subscriber key management). This way CAs would be >> incentivized >> > to >> > > > manage their business relationships more carefully since their >> business >> > > > partners could cause them audit issues. This has some precedent >> since >> > in >> > > > the past some resellers acted as RAs and had their own subordinates >> -- >> > a >> > > > practice that was terminated as they came under scrutiny and demands >> > for >> > > > audits. >> > > > >> > > > Mozilla, of course, cannot amend the BRs itself. However, past >> evidence >> > > > suggests that if the Mozilla program introduces their own >> requirements >> > > > around reseller management and disclosure then the probability of a >> > CABF >> > > > ballot with similar restrictions passing is relatively high (thus >> > getting >> > > > it into the audit regime). >> > > > >> > > > -Paul >> > > >> > > _______________________________________________ >> > > dev-security-policy mailing list >> > > dev-security-policy@lists.mozilla.org >> > > https://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 >> > >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
