How about something simple like:

(Rephrase terminology etc. as necessary)

If a CA has any arrangements with any 3rd parties to act as
intermediaries between the subscriber and the CA, while not being the
party that operates the normal uses of the private key on the
subscribers behalf, the CA must ensure that any activities by such 3rd
parties and related to certificates chaining to the CA comply fully with
the applicable BR and CPS requirements applicable to the CA performing
similar activities.

Additionally, subscribers must not be forced or encouraged to have 3rd
parties operate the normal uses of the private key on the subscribers

On 05/03/2018 20:47, Matthew Hardeman 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.

They have specialized access to bulk ordering interfaces, generally
pursuant to a reseller contract.  They're not literally hand-entering data
as though they themselves were the end-user.

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)".

On Mon, Mar 5, 2018 at 8:42 AM, Eric Mill via dev-security-policy <> 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 <> wrote:

Considering that the Baseline Requirements explicitly acknowledge that
Applicant may delegate the obtaining of their certificates to a
(Applicant Representative), how would you propose that the applicant's
agents (which, in a legal sense, is the name for their employees - that
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
What role are you suggesting that the CA has to play in policing 'how'
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 <> 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
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 <> 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 ( wrote:


It's also clear from the experience that rules of the road for
are unclear, and that accountability is limited. It seems possible,
likely, that other resellers may also be mishandling customer keys

So, what would useful next steps be to improve security and
for resellers?

As you already suggested an official communication requesting
from the CAs about the way their reseller networks manage
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
simplistic as a PCI self-assessment questionnaire?). While that
prevent bad behavior it would generate an evidence trail for
relationships with incompetent/malicious actors.

I'm not sure that that would be reasonable. After all resellers can
resellers, and so on so where would that end? With the end user
accept a "general license agreement"? And distrusting a reseller
be difficult.

I think it will have to be/remain the responsibility of the CA to
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
resellers since they probably consider that competitive
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
to create a section defining requirements placed upon resellers
around subscriber key management). This way CAs would be
manage their business relationships more carefully since their
partners could cause them audit issues. This has some precedent
the past some resellers acted as RAs and had their own subordinates
practice that was terminated as they came under scrutiny and

Mozilla, of course, cannot amend the BRs itself. However, past
suggests that if the Mozilla program introduces their own
around reseller management and disclosure then the probability of a
ballot with similar restrictions passing is relatively high (thus
it into the audit regime).


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list

Reply via email to