I agree with Sleevi on this, the real question on what can and should be done here is dependent on who the reseller is an agent of and what role they play in the overall ecosystem.
While it is easy to say that resellers are pure marketers with no vested interest in security outcomes, and there is some truth to this, the reality is far more complex. For one there is no one size fits all definition for a reseller, for example: - Hosting “reseller” - As a hosting provider, for example one that utilizes CPANEL, you may be responsible for enrolling for certificates and generating keys for users as well as managing the lifecycle, you are clearly acting “as a reseller” if you are selling “a certificate” but you are also acting as a delegate of the user if you are configuring and managing SSL for them. - SaaS “reseller” - As a SaaS provider, for example one that hosts Wordpress, you may be responsible for enrolling for certificates and generating keys for users as well as managing the lifecycle, you are clearly acting “as a reseller” if you are selling “a certificate” but you are also acting as a delegate of the user if you are configuring and managing SSL for them. - Marketing “resellers” - As a pure reseller, for example one that offers regional sales and marketing support, again you are clearly acting as a delegate of the CA by providing marketing and sales support for a vertical, region or market segment, but you could very well be providing value added services to the user (such as simplfying enrollment and/or SSL configuration) and as such are again a delagate of both parties. As I look at this non-exhaustive list, it seems to me the difference between the reseller and a and the more typical SaaS service provider where SSL is possibly a paid feature is the sale of a certificate. With that said, since there are so many different types of “other parties” it is probably better to avoid discussing resellers directly and focus on responsibilities of “other parties” instead. For example, today the BRs require that CAs and RAs: - Require consent to subscriber key archival (section 6.1.2), - Require the encryption of the subscribers private in transport (section 6.1.2). In no particular order here are some questions I have for myself on this topic: - Should we provide a definition of “other parties”, and “reseller” and make sure they are clear so responsibilities of parties are unambiguous? - In the BRs we currently say “Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key” (in Section 6.1.2) should we also say that the CAs should be required to demonstrate they have communicated this requirement to the other party and get affirmative acknowledgement from the “other party” during their audits? - The BRs currently state subscriber authorization is required for archival but there is no text covering what minimal level of authorization expressed. I would have thought this not necessary but TrustIco has been arguing users should have implicitly known they had this practice even though it was not disclosed and there was no explicit consent for archival. While I think that is a irresponsible position the text could be made clearer. - The current BR text talks about RAs generating keys on behalf of the subscriber (6.1.2 but it says nothing about other parties? - Should the BRs be revised to require CAs to have the “other parties” publicly disclose if they generate keys for users, how they protect them at rest and in transport, and how they capture consent for these practices if at all? - Though the concept of key archival for RAs and CAs is allowed in the BRs (section 6.1.2) it does not require keys be encrypted while in archive, Should this be changed? At the same time should we mandate some minimal level of protection that would prevent all user keys being accessed without user consent like was done here? - Today the BRs inconsistently discuss private key archival, for example section 6.2.5 talks about CA key archival but not subscriber archival. Should we fix this? - Should we formalize a proof proof of possession mechanism, such as what is done in ACME, as an alternative to sharing the actual key as to encourage this approach to be used instead of distribution of the actual key? One thing for us to keep in mind while looking at these issues is we are moving to a world where SSL is the default and for that to be true we need automation and permissionless SSL deployment (e.g. automation) is necessary for that to be a reality. This discussion is probably better for the CABFORUM public list but since the thread started here I thought it best to share my thoughts here. Ryan Hurst Google Trust Services _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
