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
