Re: Final Decision by Google on Symantec

2017-08-01 Thread Gervase Markham via dev-security-policy
On 28/07/17 07:14, Gervase Markham wrote:
> I would like to make a decision on this matter on or before July 31st,

After listening to the opinions here on m.d.s.p., and consultation
within Mozilla and with our engineering teams, on the matter of when to
distrust various bits of the existing Symantec PKI we have decided to
match the dates proposed by Google for Chrome (within a few weeks; exact
Firefox releases will be determined nearer the time).

This is not the outcome we would have preferred (clearly, as it doesn't
match our earlier proposal) but, given the choice before us, the
benefits of a consistent cross-browser approach have been judged to be
greater than the benefits of Mozilla unilaterally setting an earlier date.

We expect these dates to be hit; we would look dimly on any last-minute
requests to move them. I would also reiterate, in case it becomes
relevant, that any change of control of some or all of Symantec's roots
would not be grounds for a renegotiation of these dates.

We hope that we can now move swiftly to the implementation phase, and
that as it progresses we will see improved levels of security for web
users and improved confidence in the WebPKI. We will be expecting and
looking for exemplary standards of CA best practice from Symantec in
general, and their new PKI in particular, going forward.

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


Re: Found something I can't understand in these cerificates.

2017-08-01 Thread Nick Lamb via dev-security-policy
On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei  wrote:
> 1. the CN of two cerificates are same. So it is not necessary to issue two 
> certificates in just 2 minutes.

I think the most likely explanation is the difference in signature algorithm, 
but it is also not uncommon for subscribers to have more than one certificate 
fo the same name for operational reasons, this is not prohibited although it 
can be useful to watch for the rate at which this happens to an issuing system 
as a possible sign of trouble.

> 2. second one used SHA1, though is consistent with BR, but first one used 
> SHA256.

It is possible that a customer ordered a certificate and then, very quickly but 
alas after issuance they realised they had more specific needs, the SHA-256 
algorithm and the longer expiry date. Or maybe even they simply asked for the 
longer expiry and WoSign correctly pointed out that it would silly to use SHA-1 
with the longer expiry as it was to be (and has been) distrusted by that date.

> 3. first one has 39 month period of validity which is very rare.

Although rare this is permissible, and even, if the subscriber had a previous 
certificate for roughly the same name, a common business practice in order to 
secure customer loyalty.

> 4. Since they are issued so close they should be logged at CT same time but 
> second one are too late.

CT logging was not mandatory at the time, and WoSign subsequently volunteered 
to upload all the extant certificates in mid-2016 during Mozilla's 
investigation of other (serious) problems.

I think these certificates are, though perhaps not entirely regular, not a sign 
of any problem at WoSign.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Final Decision by Google on Symantec

2017-08-01 Thread Gervase Markham via dev-security-policy
On 31/07/17 15:17, Jakob Bohm wrote:
> I am referring to the fact that EV-trust is currently assigned to roots,
> not to SubCAs, at least as far as visible root store descriptions go.

You said the problem was Mozilla-specific; do other root stores not do
it this way?

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


Re: Expired Certificates Listed by Certificate Manager

2017-08-01 Thread userwithuid via dev-security-policy
On Wednesday, July 26, 2017 at 12:55:06 AM UTC, David E. Ross wrote:
> Under the Servers tab for Certificate Manager, I see several root
> certificates whose expiration dates have passed.  I believe these were
> all marked untrusted at one time.  For example, I see six DigiNotar
> certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
> others.  Is it safe to delete these?

IIRC, Mozilla just likes to keep expired distrust around because it cannot be 
overridden in the UI, whereas expired or unknown certs might be something a 
regular user might consider not that big of a deal and click through.


In this context @Mozilla: Those additional distrust entries are coming from 
NSS, but they are all pre-OneCRL afaics. Is this coincidence (= there wasn't 
any "high-profile" enough distrust warranting nss addition) or has the 
certdata-based distrust been entirely obsoleted by OneCRL (= there will never 
be any new distrust entries in certdata)?

I'm asking because some/most linux distros consume certdata, and they usually 
do have some blacklist capability where they put the certdata based distrust, 
but I don't know of any that parses OneCRL. I guess they all should, right?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Found something I can't understand in these cerificates.

2017-08-01 Thread Han Yuwei via dev-security-policy
https://crt.sh/?id=7040227
https://crt.sh/?id=30328289

I am confused for those reasons.

1. the CN of two cerificates are same. So it is not necessary to issue two 
certificates in just 2 minutes.
2. second one used SHA1, though is consistent with BR, but first one used 
SHA256.
3. first one has 39 month period of validity which is very rare.
4. Since they are issued so close they should be logged at CT same time but 
second one are too late.

So is there some common parctice I don't know or another mistake made by Wosign?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Final Decision by Google on Symantec

2017-08-01 Thread userwithuid via dev-security-policy
WRT to the deadlines: If the decision is to sync up, I think it's worth noting 
that Firefox probably needs to release 2-3 weeks after a Chrome "release date" 
to achieve this in practice.

Why? Firefox updates take ~10days from release date to reach previous version 
numbers. Chrome _can_ do it in the same time, but sometimes they slow update 
propagation considerably - and the distrust events could very well be reasons 
to do this.

Take for example Chrome 57: Release date for desktop was March 9 [1], but 
propagation was throttled heavily for the first ~20 days, resulting in a total 
of ~30 days. [2] Chrome 57 for Android, supposedly released March 16 - always a 
week later than desktop! - was also held back for most? users for ~3-4 weeks 
iirc (can't find a graph right now, sorry).

So unless Mozilla is eager to deal with most of the immediate outfall of the 
trust changes on its own (at which point we might as well set stricter 
deadlines), it should strategically fall behind.

Dates in question:
* Firefox 60 on 2018-05-01 for old PKI notBefore >=2016-06 -> already close, 
only 2 weeks after
* Firefox 64 on 2018-11-27 for the full distrust -> 5 weeks after. Bonus: All 
the 1-year certs from the old PKI will have expired as well.

[1] 
https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html
[2] 
http://gs.statcounter.com/browser-version-market-share/desktop/worldwide/#daily-20170301-20170501





On Monday, July 31, 2017 at 2:01:57 PM UTC, Gervase Markham wrote:
> On 29/07/17 23:45, Peter Bowen wrote:
> > First, when the server authentication trust will bits be removed from
> > the existing roots.  This is of notable importance for non-Firefox
> > users of NSS.  Based on the Chrome email, it looks like they will
> > remove trust bits in their git repo around August 23, 2018.  When will
> > NSS remove the trust bits?
> 
> The NSS trust store represents Mozilla's decisions about what is
> trustworthy. However, particularly if we match Chrome's dates, there is
> a slightly unusual situation as we have taken a decision on
> trustworthiness but, for other reasons, Firefox still trusts those certs
> for a period. So one might well ask, should the decision be implemented
> in NSS earlier than, or at the same time as, or even later than, Firefox
> implements it? A good question.

If you enjoy making things harder for other people you can go with earlier :-P 
. Seriously though, that would only make sense from a Mozilla release process 
perspective but is totally unexpected and annoying for any other NSS consumer - 
they will just have to postpone that NSS update or restore the roots 
temporarily.

I think it makes most sense to land Firefox internal distrust shortly before 
branching, like Chrome, use beta for gauging impact, release, then ~2 weeks 
after release date do a NSS point release with only the certdata changes for 
other consumers and future Firefox versions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy