On Mon, Mar 5, 2018 at 2:47 PM Matthew Hardeman <[email protected]> wrote:
> In terms of an "opportunity" to insert regulation into the reseller > ecosystem, as Mr. Sleevi points out, there is the question of whether the > reseller is just a third party agent acting under contract by the end-user > client vs a party with a special relationship with one or more CAs and > their own end-user sales channel soliciting customers. > > Ultimately, the reality is that the resellers all have interfaces offering > some level of automated processing for bulk ordering. These resellers > aren't acting as literal extra hands on behalf of the end user. > Many do. > They have specialized access to bulk ordering interfaces, generally > pursuant to a reseller contract. > Not always. They're not literally hand-entering data as though they themselves were > the end-user. > Some do. It's the existence of that relationship and access which provides an > opportunity for the community to decide "If the CA has relationships in > this nature, the CA has an affirmative duty to ensure as a condition of the > relationship that _______ (insert rules)". > Sure, and when CAs switch the relationships to not be of that nature, but one slightly different - or when it’s the user’s agents that have failed - we have accomplished nothing but introduce more complexity for no gain, because the underlying problems remain. And I worry that such complexity will limit the flexibility to solve real problems. I don’t hear calls for suggesting that browsers should not connect if the domain was registered through a registrar with less than stellar domain hygeine, or refusing to connect to domains hosted by hosting providers that may store user passwords unsalted, but that is really the degree of “basic infrastructure” we are talking about here. I do deeply worry that the amount of energy spent here trying to contemplate policy on this will drain energy from the far more important efforts, such as ensuring reliable, interoperable automation, such that the very need to generate a CSR by hand evaporates. If we can get there, we have solved the problems resellers are trying to solve, better, more securely, and without having to invent paper tigers so we can waggle our fingers when they fail. > > > On Mon, Mar 5, 2018 at 8:42 AM, Eric Mill via dev-security-policy < > [email protected]> 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 < >> [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 >> > >> >> >> >> -- >> konklone.com | @konklone <https://twitter.com/konklone> >> > _______________________________________________ >> 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
