Re: Following up on Trustico: reseller practices and accountability

2018-03-11 Thread Eric Mill via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-06 Thread Jakob Bohm via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Nick Lamb via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Sleevi via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Hurst via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Matthew Hardeman via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Matthew Hardeman via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Sleevi via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Hurst via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Sleevi via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Sleevi via dev-security-policy
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. > > >

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread okaphone.elektronika--- via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread okaphone.elektronika--- via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Eric Mill via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread James Burton via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread Ryan Sleevi via dev-security-policy
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,

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread James Burton via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-05 Thread 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

Re: Following up on Trustico: reseller practices and accountability

2018-03-04 Thread Ryan Sleevi via dev-security-policy
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

Re: Following up on Trustico: reseller practices and accountability

2018-03-04 Thread Anis via dev-security-policy
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