Hi Jakob,
Your below description raises two questions of general interest (though not of
interest to the Mozilla root program):
1. Will DigiCert establish cross-signatures from the old/historic
Symantec roots to continuing DigiCert roots and subCAs?
[JR] We won’t be cross-signing from Digi
s concerns.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec
, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal
Steve,
Thank you for responding relatively promptly (at least as compared to previous
Symantec responses) to Devon's questions.
However, these responses seem to imply that a side effe
One good thing we should be able to hope for from a change in ownership even if
the personnel and equipment are the same or a great deal in common: improved
management oversight. In my view the most worrying underlying problem at
Symantec was the inadequate oversight. Senior management at the co
f
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just
s.mozilla.org
> Subject: [EXT] Re: Symantec Update on SubCA Proposal
>
> Hello m.d.s.p.,
>
> I'd just like to give the community a heads up that Chrome’s plan remains to
> put up a blog post echoing our recent announcement on blink-dev [1], but
> in the meantime, we are
Hello m.d.s.p.,
I'd just like to give the community a heads up that Chrome’s plan remains to
put up a blog post echoing our recent announcement on blink-dev [1], but in the
meantime, we are reviewing the facts related to Symantec’s sale of their PKI
business to DigiCert [2].
Recently, it has c
Just to be explicit: your count includes certificates which, with high
probability have already been replaced, because it does not subtract names
for which new certificates have been issued?
I realize it may seem like I'm putting a lot of emphasis on this one
number, but given that it's the basis
On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> wrote:
>
> > Symantec has proposed timing changes that are consistent with the scope of
> > distrust of the original SubCA proposal as proposed by Google a
On 25/07/2017 22:28, Rick Andrews wrote:
...
You are correct in that most customers are indeed not prepared to
deal with potential crises in the SSL system. We have all witnessed
this first hand with Heartbleed, the replacement of SHA1
certificates, etc. A four month replacement window for a
On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Symantec has proposed timing changes that are consistent with the scope of
> distrust of the original SubCA proposal as proposed by Google and endorsed
> by Mozilla, which requir
On Tuesday, 25 July 2017 21:29:06 UTC+1, Rick Andrews wrote:
> The details of this process would probably be best served in a separate
> thread. Essentially, such a process would involve a quick assessment by the
> community on the context and merits of the request by the customer
You want us t
On Monday, July 24, 2017 at 2:50:22 AM UTC-7, Gervase Markham wrote:
> Hi Rick,
>
> Some more thoughts on your post. I continue to invite community
> commentary on the issues we are discussing.
>
> On 21/07/17 07:00, Rick Andrews wrote:
> > In our June 1 post, we stated that we would update the c
Hi Rick,
Some more thoughts on your post. I continue to invite community
commentary on the issues we are discussing.
On 21/07/17 07:00, Rick Andrews wrote:
> In our June 1 post, we stated that we would update the community after the
> end of the month.
Indeed. I was more referring to the sugge
On 21/07/17 07:00, Rick Andrews wrote:
> In light of all of these implications, we respectfully request that Mozilla,
> Google and the community consider the dates Symantec has proposed, which are
> the results of our earnest and extensive efforts to implement the spirit of
> the SubCA proposal.
On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
>
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
>
Hi Steve,
Thanks for posting this. I appreciate the level of detail provided,
which is useful in giving us a basis for discussion. It's a little
regrettable, though, that it was published a couple of weeks after we
were led to expect it...
One note before we start: Symantec's business dealings re
On 20/05/17 15:26, Michael Casadevall wrote:
> However, for Mozilla's purposes, is there a case where having a SCT in
> certificate would either break something, or otherwise be undesirable?
I believe we turned the checking on and discovered performance issues,
so we turned it off. I'm not sure if
On 05/19/2017 10:25 AM, Gervase Markham wrote:
> Embedding SCTs is not the only way SCTs can be delivered - they can come
> in the SSL handshake or via OCSP. Requiring them to be embedded does
> have the advantage that certificates now carry an unforgeable timestamp,
> and it was something I propos
On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate. They have indicated that the SSP customers have
> some level of issuance capability.
Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.
Gerv
_
On Fri, May 19, 2017 at 7:25 AM, Gervase Markham via
dev-security-policy wrote:
> On 15/05/17 21:06, Michael Casadevall wrote:
>
>>> Are there any RA's left for Symantec?
>>
>> TBH, I'm not sure. I think Gervase asked for clarification on this
>> point, but its hard to keep track of who could issu
On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any
On 05/16/2017 03:50 AM, Michael Casadevall wrote:
> On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>>
>
> - A three-day grace period shall be in place from the issuance date of
> a certificate to when it must be in the CT logs for validation reasons
> (this is in line with other proposals here).
>
>
On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>
> Ok, that's much better.
>
Yay for reasonable courses of action. We'll see if it goes into the next
proposal.
>> I can see the point here, but I'm not sure I agree. Every time we keep
>> digging, we keep finding more and more problems with these roots
On 15/05/2017 22:06, Michael Casadevall wrote:
On 05/15/2017 09:32 AM, Jakob Bohm wrote:
This won't work for the *millions* of legitimate, not-misissued,
end certificates that were issued before Symantec began SCT
embedding (hopefully in the past) and haven't expired before such
an early deadlin
On 05/15/2017 09:32 AM, Jakob Bohm wrote:
> This won't work for the *millions* of legitimate, not-misissued,
> end certificates that were issued before Symantec began SCT
> embedding (hopefully in the past) and haven't expired before such
> an early deadline.
>
Sorry, I could have been more clear
On 13/05/2017 12:27, Michael Casadevall wrote:
On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:
On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy
wrote:
I would appreciate people's comments on the details of the current draft.
I don’t think that t
On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:
>
>> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy
>> wrote:
>>
>> I would appreciate people's comments on the details of the current draft.
>
> I don’t think that this proposal goes far enough.
Firs
On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham wrote:
> On 11/05/17 13:02, wiz...@ida.net wrote:
> > That said, it is fair point that the plan should spell out what happens if
> > symantec does not cooperate.
>
> I think we should cross that bridge when we come to it, which I hope we
On 11/05/17 13:02, wiz...@ida.net wrote:
> That said, it is fair point that the plan should spell out what happens if
> symantec does not cooperate.
I think we should cross that bridge when we come to it, which I hope we
won't. Not that I'm not prepared to cross it, but there's no point
devising
> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy
> wrote:
>
> I would appreciate people's comments on the details of the current draft.
I don’t think that this proposal goes far enough.
Symantec has demonstrated that they have no interested in engaging with the
Mozilla co
Possibly this is irrelevant, but I have some concerns on how Symantec, it seems
to me, is willfully mischaracterizing their certificate compliance issues in
their prepared remarks to their investors yesterday.[1]
It makes it sound as if there are some generic certificate industry changes
that a
Symantec, in previous blog posts on their site, has indicated that they will
support their customers [1].
That said, it is fair point that the plan should spell out what happens if
symantec does not cooperate. It seems appropriate to have the plan do what it
says -- scheduled phase out of the o
On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> > The next step, if Symantec wish to continue to use their current PKI in
> the future, should be logging (
On Tue, May 09, 2017 at 07:03:16PM +0200, Kurt Roeckx via dev-security-policy
wrote:
>
> Instead of the removal of the roots, I suggest we either ask them
> to revoke all the intermediate CAs that do not have the required
> audits or that Mozilla adds them to OneCRL.
Just to clarify, I believe t
On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> The next step, if Symantec wish to continue to use their current PKI in the
> future, should be logging (ASAP) *all* of the certificates they issued to a
> CT log, then we'll know how deep is the rabbit hole.
already the case
On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham wrote:
> On 09/05/17 16:51, Gervase Markham wrote:
> > * Editing the proposal to withdraw the "alternative" option, leaving
> > only the "new PKI" option.
>
> This has now been done:
>
> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb
The next step, if Symantec wish to continue to use their current PKI in the
future, should be logging (ASAP) *all* of the certificates they issued to a CT
log, then we'll know how deep is the rabbit hole.
___
dev-security-policy mailing list
dev-securit
On 09/05/17 16:51, Gervase Markham wrote:
> * Editing the proposal to withdraw the "alternative" option, leaving
> only the "new PKI" option.
This has now been done:
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
> * Engagement here in m.d.s.p. with the co
On Tuesday, May 9, 2017 at 10:03:53 AM UTC-7, Kurt Roeckx wrote:
>
> Do we somewhere have the official templates being used to send
> reminders of the audit requirements?
Unofficial templates:
https://wiki.mozilla.org/CA:Email_templates
The official templates are in Salesforce, but currently m
On Tue, May 09, 2017 at 04:51:12PM +0100, Gervase Markham via
dev-security-policy wrote:
> Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the si
On 09/05/17 17:29, Vincent Lynch wrote:
> I have one question regarding your wording. You write"I am therefore
> *proposing
> *the following," and then you list your changes.
>
> Does this mean that the "alternative" option is officially, 100%, off the
> table? Or is this still an option Kathleen
Hi Gervase,
Thank you for the update on Mozilla's process.
I have one question regarding your wording. You write"I am therefore *proposing
*the following," and then you list your changes.
Does this mean that the "alternative" option is officially, 100%, off the
table? Or is this still an option
43 matches
Mail list logo