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 for your assertion about the relative difficulty for different distrust dates, I think it's quite significant. Given that your methodology appears to over-count (to the advantage of laxer distrust policies!), and cannot be independently verified, it really boils down to "trust us to do right by the security of the WebPKI". Not to put too fine a point on it, but we're in this situation because of Symantec's history of _not_ acting in the interests of the security of the WebPKI. It seems to me you could improve the transparency of this process by logging all DV certs from this time frame to CT. Alex On Thu, Jul 27, 2017 at 11:53 AM, Rick Andrews via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 and > endorsed > > > by Mozilla, which requires premature replacement of over 234,000 > > > certificates based on our proposed May 1, 2018 distrust date for > > > certificates issued before June 1, 2016, and optimizes for replacement > > > certificates to be issued off the new Managed CA(s) infrastructure > > > (avoiding the requirement for double early replacement for the same > > > original validity period). We believe our proposal minimizes > disruption to > > > websites and web end-users while meeting the spirit of Google’s and > > > Mozilla’s prior commentary on their intent regarding the SubCA > proposal, > > > which is to limit the issuance of Symantec certificates under > Symantec’s > > > existing infrastructure and governance. > > > > > > > Hi Rick, > > > > Given the importance of this 234,000 number, I was curious to explore. > > Using the list of certificates Peter Bowen previously put together ( > > https://groups.google.com/a/chromium.org/d/msg/blink-dev/ > eUAKwjihhBs/aQqYZX6oBgAJ), > > I ran a small script to filter out ones that expire before May 2018, or > > were issued after June 2016. Using this methodlogy, I got a count of > 166k, > > a deviation of ~70k from your number. My 166k includes any certificates > > that have been replaced since Peter put together the list in April, so in > > that sense it likely reflects an over estimate of the number of certs > > needing to be replaced. > > > > Can you say a little more on how you came to this number? > > > > Cheers, > > Alex > > Our reference to over 234,000 certificates is based on our internal > records of all active, unrevoked certificates that we issued prior to June > 1, 2016 that expire after May 1, 2018. The dataset you reference relies on > CT logs, which includes all active EV certificates Symantec has issued > before June 1, 2016, but does not include all active, unrevoked OV and DV > certificates Symantec has issued before June 1, 2016. > _______________________________________________ > 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
