Inspired by David's message, 2 suggestions for the Symantec plan:
1. Mozilla - and ideally Google as well - should clearly and explicitly
communicate in the official statement on this that the "new" Symantec will
still be strictly monitored even after the current remediation plan has been
On Tuesday, June 6, 2017 at 2:03:29 PM UTC, Gervase Markham wrote:
>
> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted
On 06/06/2017 22:08, Ryan Sleevi wrote:
On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am saying that setting an administrative policy for inclusion in a
root program is not the place to do technical reviews of security
On 6/6/2017 12:10 PM, Peter Kurrasch wrote:
> Over the past months there has been much consternation over Symantec and
> the idea of "too big to fail". That is a reasonable idea but makes
> difficult the discussion of remedies for Symantec's past behavior: How
> does one impose a meaningful
On Monday, June 5, 2017 at 11:17:17 AM UTC-5, Ryan Sleevi wrote:
> While on paper the idea sounds quite good, it turns out to simply trade
> technical complexity for complexity of the non-technical sort. As such,
> it's best to focus on meaningful and actionable technical solutions.
Ryan,
I
On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I am saying that setting an administrative policy for inclusion in a
> root program is not the place to do technical reviews of security
> protocols.
Of course it is. It is the
On Tuesday, June 6, 2017 at 4:14:00 AM UTC-5, Gervase Markham wrote:
> On 05/06/17 14:29, Alex Gaynor wrote:
> > As I've expressed before, I find it baffling that this still happens.
>
> I am also disappointed. I have half a mind to keep track of how often
> this happens per CA, and impose a
On Tuesday, June 6, 2017 at 9:03:29 AM UTC-5, Gervase Markham wrote:
> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>
> 1) Scope of Distrust
>
> Google proposal:
Over the past months there has been much consternation over Symantec and the idea of "too big to fail". That is a reasonable idea but makes difficult the discussion of remedies for Symantec's past behavior: How does one impose a meaningful sanction without causing Symantec to fail outright since
On 06/06/2017 16:02, Gervase Markham wrote:
On 02/06/17 15:53, Gervase Markham wrote:
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
I'm slightly surprised to see no engagement here. Perhaps it would be
help to break it down. Symantec's specific requests
I broadly echo many of the comments and thoughts of Martin Heaps earlier in
this thread.
Much of Symantec's response is disheartening, especially in the "inaccuracies":
(the apparent dichotomy between how they have acted and their statement that
they only employ the best people implementing
On 06/06/2017 07:45, Ryan Sleevi wrote:
On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
If you read the paper, it contains a proposal for the CAs to countersign
the computed super-crl to confirm that all entries for that CA
Here are some thoughts from me:
On 06/06/17 15:02, Gervase Markham wrote:
> 1) Scope of Distrust
I have sought more information from Google on this.
> 2) Timeline
I think the question here is, what is our position, and on what basis do
we decide it? If we want to impose an aggressive but
Hello all,
I also did it but it´s not reflected.
In my case was also my fault because I was disclosing a different one.
Best regards
Iñigo Barreira
CEO
StartCom CA Limited
-Original Message-
From: dev-security-policy
On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-
> response-google-s-subca-proposal
>
> I'm slightly surprised to see no
Hello:
I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB. The
omission was human error (my own) when entering a group of issuing CAs into
SalesForce. Ongoing, when new ICAs are created, the CCADB disclosure is
part of our process.
For the sake of clarity, that ICA is disclosed
On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote:
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
Alex, do you have the specific list of CAs at the time of your posting?
Yes, it was:
* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 05/06/17 14:29, Alex Gaynor wrote:
> > > As I've
On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 05/06/17 14:29, Alex Gaynor wrote:
> > As I've expressed before, I find it baffling that this still happens.
>
> I am also disappointed. I have half a mind to keep track of
On Tue, Jun 06, 2017 at 10:13:20AM +0100, Gervase Markham via
dev-security-policy wrote:
> Aside from taking a note of how often this happens and it perhaps
> appearing in a future CA investigation as part of evidence of
> incompetence, does anyone else have ideas about how we can further
>
On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".
So you think we should use the word "misissuance" for all forms of
imperfect issuance, and then have a gradated reaction depending on the
type and circumstances, rather than use the
On 05/06/17 14:29, Alex Gaynor wrote:
> As I've expressed before, I find it baffling that this still happens.
I am also disappointed. I have half a mind to keep track of how often
this happens per CA, and impose a mandatory delay of 1 month per
incident to that CA's next attempt to include a new
On 05/06/17 16:52, Matthew Hardeman wrote:
> Has there ever been an effort by the root programs to directly assess
> monetary penalties to the CAs -- never for inclusion -- but rather as
> part of a remediation program?
Another fact to bear in mind when discussing this is that, for a number
of
On 02/06/17 17:07, Peter Bowen wrote:
> Should Mozilla include a clear definition of "SSL certificates" in the
> policy? And should it be based on technical attributes rather than
> intent of the issuer?
Absolutely Yes to your second sentence :-). We do have a clear
definition of what's in
On 02/06/17 17:24, Kurt Roeckx wrote:
> On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
>> On 02/06/17 12:24, Kurt Roeckx wrote:
>>> Should that be "all certificates" instead of "all SSL certificates"?
>>
>> No; the Baseline Requirements apply only to SSL certificates.
>
> Then I
On 02/06/17 12:29, Ryan Sleevi wrote:
> 2) "performing RA or DTP functions"
I'll go with that :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
26 matches
Mail list logo
