...@lists.mozilla.org
Subject: Re: [EXT] Symantec: Draft Proposal
To ask a substantive question, you have asserted that all certificates issued
have been logged to CT; this Symantec CA currently has no publicly logged
issued certificates:
https://crt.sh/?sha256
Hello Rick,
This weekend you asked "customers and the browser community to pause on
decisions related to this matter until final proposals are posted and
accepted."
More than 48 hours ago I asked if you could provide someone sort of
estimate on when this proposal would be ready to be shared with
On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote:
> Hi Rick,
>
> I don't see a "May 4th post". Where was it posted? Not here it seems.
It's above--it links to
https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
>
> Also it's reasonable that S
Hi Rick,
Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?
If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
many of
It makes perfect sense if the game plan is to force continued delays of
decisions on the part of root programs! Which appears to be exactly what is
happening. After all, wait long enough, and it can be claimed that all possibly
bad things would be expired, so don't distrust us, m'ok.
I think th
Am Montag, 8. Mai 2017 00:09:19 UTC+2 schrieb Rick Andrews:
> We urge Symantec customers and the browser community to pause on decisions
> related to this matter until final proposals are posted and accepted. The
> intent of both Google and Symantec is to arrive at a proposal that improves
> se
Hi Rick,
I don't see a "May 4th post". Where was it posted? Not here it seems.
Also it's reasonable that Symantec wants to "address impact to their customers"
but what about impact to all of the browsers users? It may be a good idea to
try and address (in your proposals) that to.
So far I have
On Sunday, May 7, 2017 at 6:09:19 PM UTC-4, Rick Andrews wrote:
> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with Google.
>
>
> Following our May 4th post, senior executives at Google and Symantec
> established a new dialogue
On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with
> Google.
>
> Following our May 4th post, senior executives at Go
On Sun, May 07, 2017 at 03:09:10PM -0700, Rick Andrews via dev-security-policy
wrote:
> We urge Symantec customers and the browser community to pause on decisions
> related to this matter until final proposals are posted and accepted.
You appear to be saying that Mozilla doesn't have anything to
I'm posting this on behalf of Symantec:
We would like to update the community about our ongoing dialogue with Google.
Following our May 4th post, senior executives at Google and Symantec
established a new dialogue with the intention to arrive at a new proposal for
the community that addresse
On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-
> con
On 05/05/2017 17:37, Gervase Markham wrote:
On 04/05/17 19:30, Jakob Bohm wrote:
1. Issue D actually seems to conflate three *completely different*
issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
I am referring to the "summary" of D in
On Fri, 5 May 2017 17:18:38 +0100
Gervase Markham via dev-security-policy
wrote:
> On 05/05/17 17:09, Peter Bowen wrote:
> > We know that the RAs could use different certificate profiles, as
> > certificates they approved had varying issuers, and "Issuer DN" has
> > the same "No(1)" that CP has i
On Fri, May 5, 2017 at 9:18 AM, Gervase Markham wrote:
> On 05/05/17 17:09, Peter Bowen wrote:
>> We know that the RAs could use different certificate profiles, as
>> certificates they approved had varying issuers, and "Issuer DN" has
>> the same "No(1)" that CP has in the table in the doc you lin
On 05/05/17 17:09, Peter Bowen wrote:
> We know that the RAs could use different certificate profiles, as
> certificates they approved had varying issuers, and "Issuer DN" has
> the same "No(1)" that CP has in the table in the doc you linked. I
> don't see any indication of what profiles each RA w
On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via
dev-security-policy wrote:
> On 04/05/17 21:58, Ryan Sleevi wrote:
>
> I asked Symantec what fields CrossCert had control over. Their answer is
> here on page 3:
> https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
> It says CrossCer
On 05/05/17 04:30, Steve Medin wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
It feels somewhat strange to have this disjointed blog-vs.f
On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the
evidence that there were issues
> and patterns that were unresolved, and thus sought to minimize the impact
> of an eventual total distrust in a gradual way.
So the first Chrome proposal had the explicit target of an eventual
total
On 04/05/17 19:30, Jakob Bohm wrote:
> 1. Issue D actually seems to conflate three *completely different*
> issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
> 2. If the remaining unconstrained SubCAs are operated by Symantec and
> subject t
gt; Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec: Draft Proposal
> >
> > Here is my analysis and proposal for what actions the Mozilla CA
> Certificat
On 2017-05-04 22:55, Alex Gaynor wrote:
I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.
The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or th
Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec: Draft Proposal
> >
> > Here is my analysis and proposal for what actions the Mozilla CA
> Certificates
> > module owner shou
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > wizard--- via dev-security-policy
> > Sent: Tuesday, May 02, 2017 7:10 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec: Draft Proposal
> >
> >
> > A
illa.org
> Subject: [EXT] Symantec: Draft Proposal
>
> Here is my analysis and proposal for what actions the Mozilla CA
Certificates
> module owner should take in respect of Symantec.
>
[snip]
> Please discuss the document here in mozilla.dev.security.policy. A good
> timefra
Gerv,
Regarding your understanding of the “First Chrome Proposal”, which seems to
have influenced your “Alternative” suggestions, some quick clarifications:
(Wearing a Chrome/Google hat here)
The first Chrome proposal was operating on the concern that a complete and
total removal of trust
Hi all,
This morning Symantec disclosed ~20 new intermediate certs. I went through
these and identified 7 of them which are a) not revoked, b) not expired, c)
lack a BR audit:
https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A
https://crt.sh/?q=D7D90D0FCFB5CDEC5754
On 01/05/2017 16:16, Gervase Markham wrote:
Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
Please discuss the document here in mo
So Mozilla think Symantec's issues are on t serious enough to lose trust
entirely?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
gt; Subject: [EXT] Re: Symantec: Draft Proposal
>
>
> Also, in the responses, Symantec claims that MSC Trustgate is no longer an
> RA (but could be a reseller). I did a quick search on crt.sh for recent
> certificates that have supplied by MSC Trustgate:
>
> [link]
>
Hi Steve,
On 02/05/17 18:39, Steve Medin wrote:
> Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to
> respond to your latest proposal shortly.
Please understand that this is not (yet) Mozilla's response to Symantec.
If we were a closed root program, this would be an int
kham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec: Draft Proposal
>
> Here is my analysis and proposal for what actions the Mozilla CA Certificates
> module owner should take in
On 2017-05-02 12:55, Gervase Markham wrote:
On 01/05/17 18:33, Alex Gaynor wrote:
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-befor
This seems like a very reasonable stance for Mozilla to take: strongly
encourage a new Symantec PKI so they start with a clean slate, otherwise staged
distrust of all existing certificates with the requirement that Symantec
produce a full document/diagram of how the components of their PKI are
On 01/05/17 18:33, Alex Gaynor wrote:
> One idea that occurred to me (maybe novel, though I doubt it), is requiring
> mandatory _timely_ CT submission for intermediates/cross signatures. That
> is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
> less than some period, perha
On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:
Hi Gerv,
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
Hi Gerv,
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
less than some period, perhaps 3 days. This would ensure rapid v
Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
Please discuss the document here in mozilla.dev.security.policy. A good
timeframe fo
38 matches
Mail list logo