It wouldn't stop someone from offering such a service and it also wouldn't prevent users from using that CSR as it is their choice in the end. This was just an idea. CAs shouldn't be policing users. CAs should be instead enforcing best practices on resellers as practices like this shaken user confidence to a degree which affects all.
On Mon, Mar 5, 2018 at 2:15 PM, Ryan Sleevi <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 ( >> > > [email protected]) 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 >> > [email protected] >> > https://lists.mozilla.org/listinfo/dev-security-policy >> > >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
