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
behalf.

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 <
dev-security-policy@lists.mozilla.org> 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 <
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).




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to