Re: Symantec: Update

2017-05-10 Thread Andrew R. Whalley via dev-security-policy
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 (ASAP) *all* of the certificates they issued
> to a CT log, then we'll know how deep is the rabbit hole.
>
> already the case since '15
>
> https://security.googleblog.com/2015/10/sustaining-
> digital-certificate-security.html


The blog post is dated October 15, but the requirement* only came into
effect June 1st, 2016


> although I'm not certain if this applied only to certs issued under the
> Symantec brand.


Any certs issued by any Symantec CA, regardless of brand, unless the CA is
operated by a 3rd party under its own, separate, audit.

Andrew

*required for the cert to be trusted in Chrome.  They are still free to
issue certs that don't comply with the Chrome CT Policy, but those will
cause an interstitial warning in Chrome.

___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec: Update

2017-05-10 Thread Kurt Roeckx via dev-security-policy
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 that under 4.9.1.2 of the BRs, either
point 5, 8 or 9, Symantec is required to revoke those certificates
within 7 days. There is no indication that they follow the BR
requirements, the audit report even says that Symantec does not
control them, just monitor them. They are a clear danger.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec: Update

2017-05-10 Thread mono.riot--- via dev-security-policy
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 since '15

https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

although I'm not certain if this applied only to certs issued under the 
Symantec brand. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec: Update

2017-05-10 Thread okaphone.elektronika--- via dev-security-policy
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/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
> 
> > * Engagement here in m.d.s.p. with the community to refine and flesh out
> > the "new PKI" proposal, based on the Google outline but examining it and
> > enhancing it to make sure it is practical, both from an implementation
> > perspective and to reduce disruption to sites as far as possible.
> 
> I would appreciate people's comments on the details of the current draft.

Makes sense to me.

But it does seem to assume that Symantec will cooperate with this. What happens 
if they decide not to is less clear. Perhaps it would be a good idea to 
indicate which steps will be taken in any case?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Find a 5-year certificate

2017-05-10 Thread userwithuid via dev-security-policy
In this context, I was wondering: Has there been a discussion yet on Firefox 
enforcing cert lifetime in code not just via policy?

Most everything seems to be in place already due to EV, but DV doesn't have a 
limit atm. [0]

Now in practice, thanks to killing sha1, most of those legacy certs are 
probably distrusted anyway. But then again, backdating is technically possible, 
until full CT can provide protection in ~4 years iiuc, and it's a pretty 
stealthy way for CAs to subvert current guidelines (unless you do it 
WoSign-style I guess...)

Limiting to 60 months could be done right now as a sanity check and shouldn't 
cause any problems, right?

[0] 
https://github.com/mozilla/gecko-dev/blob/455ab646d315d265b4c0c3f712a69aae40985fcf/security/certverifier/NSSCertDBTrustDomain.cpp#L1112
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Draft further questions for Symantec

2017-05-10 Thread Gervase Markham via dev-security-policy
On 08/05/17 13:24, Gervase Markham wrote:
> 8) Please explain how the Management Assertions for your December 2014


Strike this question; it's based on a misunderstanding of how audits are
done.

Let's add:

10) Do you agree that, during the period of time that Symantec
cross-signed the Federal PKI (Issue L), it was technically possible for
issuers inside the FPKI to issue EV certs by inserting Symantec's EV OID?

11) If, in the Symantec Issues list or any other document relating to
this matter we may publish in future, we have drawn a conclusion or
inference about Symantec's PKI, actions or behaviour which is incorrect,
we expect you to draw that to our attention, even if the truth is not as
favourable to Symantec. Are there any incorrect inferences or
conclusions in the Issues List which need to be corrected?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-10 Thread Gervase Markham via dev-security-policy
On 09/05/17 18:25, Doug Beattie wrote:
> I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by 
> 21st July 2017.  
> 
> I'm assuming this is the latest official draft:
> 
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md

Yes :-)

> Specifically, does this mean all new domain validations must conform to the 
> 10 methods, 
> or that all new issuance 
> must be based on domains validated with only these 10 methods?

It means that all new validations must be done using one of the 10
methods. The rules for information reuse will, I hope, be clarified in
an upcoming ballot in the CAB Forum. Assuming that ballot doesn't say
anything ridiculous, Mozilla will allow reuse according to those rules.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy