Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the
following email to its partner ecosystem:
Dear Partner,
In reaction to current events related to the private key exposure and mass
revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted
Partners and
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
On Mon, 5 Mar 2018 09:29:47 -0800 (PST)
"okaphone.elektronika--- via dev-security-policy"
wrote:
> On Monday, 5 March 2018 18:10:17 UTC+1, okaphone.e...@gmail.com
> wrote:
> Ah, found it. It was tialaramex who suggested that this could be how
> Trustico got
On Mon, Mar 5, 2018 at 2:47 PM 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
On Monday, March 5, 2018 at 11:38:31 AM UTC-8, Ryan Sleevi wrote:
> While these are interesting questions, I think it gets to the heart of
> policy questions, which is how is policy maintained and enforced. Today,
> there’s only one method - distrust.
>
> So are you suggesting the CA should be
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
On Mon, Mar 5, 2018 at 7: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
On Mon, Mar 5, 2018 at 2:17 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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
I think it would be very unreasonable, unfortunately.
Such a discussion requires defining what a reseller is - and a whole
spectrum exists in which Amazon Certificate Manager, Venafi, Dreamhost, and
more (all very different services) could unduly get swept up into such a
definition.
Further, I
On Mon, Mar 5, 2018 at 12:10 PM okaphone.elektronika--- via
dev-security-policy wrote:
> On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill wrote:
> > I think it probably makes more sense to focus on sensitive key material
> > than non-sensitive CSRs.
> >
>
On Monday, 5 March 2018 18:10:17 UTC+1, okaphone.e...@gmail.com wrote:
> On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill 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
On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill 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
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
It wouldn't stop someone from offering such a service and it also wouldn't
prevent users from using that CSR as it is their choice in the end. This
was just an idea.
CAs shouldn't be policing users. CAs should be instead enforcing best
practices on resellers as practices like this shaken user
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,
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
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:
>
>
>
> It's also clear from the experience that rules of the road for resellers
> are unclear, and that
On Sun, Mar 4, 2018 at 4:04 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So, what would useful next steps be to improve security and accountability
> for resellers?
>
It depends - do you view resellers as the user's delegated agent - that is,
much like
Le dimanche 4 mars 2018 22:06:23 UTC+1, Eric Mill a écrit :
> Last week, Trustico (a reseller, formerly for Symantec and now for Comodo)
> sent 23,000 private keys to DigiCert, to force their revocation. This
> showed that Trustico had been storing customer keys generated through one
> or more
20 matches
Mail list logo