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 >> <dev-security-policy@lists.mozilla.org> wrote: >> >> I would appreciate people's comments on the details of the current draft. > > I don’t think that this proposal goes far enough.
First post on the list but long time lurker, but I feel the need to weigh in here that I think Jonathah's proposal is much closer to what has to happen. Reading through Gervase's document, I'd like to add the following to this in addition to the existing notes in PKI operations: - EV certificate roots loose their trust bits effective immediately (I don't think this can be done via OneCRL so it would be via the next release) - Any root stores (new or old) operated by Symantec shall require all certificates to be posted to a CT log. - Within three months, require all certificates issued from Symantec to have SCT embedded in the end point certificate, and mandate this from the beginning for any root certificates. - NSS shall only accept certificates with the embedded SCT record in the certificate. Certificate transparency was the only way we began to get a real look at how bad some of these issues are, and I feel that if we're going to actually continue with Symatec as a CA, then we're going to make absolutely sure we know how certificates are being utilized. Mandating the X509v3 extension for TLS certificates means that downstream servers don't have to be updated for CT awareness, and we should never be in a case where a Mozilla product is accepting a certificate that we can't independent review at a further point via the CT logs. It should also prevent an undisclosed intermediately from being undetected (as we've seen with Issue Y). I'd also like to add the following to the transition plans: - Limit certificate expiration to nine months from the existing roots for new certificates. - The above SCT requirement shall come into affect for the old roots no less that three months from the date the proposal is ratified. - Create a whitelist of intermediate certificates from the root that can continue issuing certificates, but cutting off RAs after an initial six month time period - Require that Symantec reapply to the root program for a new DV and EV root certificates, and begin the migration here. Once the new roots are approved, then they can cross-sign from the old roots to the new ones. My thought process here is to try and keep impact on WebPKI a minimum, while making sure that we can externally audit how Symantec is using their root store for certificates that will be trusted by Mozilla. I'm concerned that spinning up new roots and having them be in the most common root stores is going to take a significant period of time and during that window we're still stuck with the old roots being in operation. By limiting the branches of the old roots, it should limit our risk while the new roots come into existence and begin to spread through the ecosystem. Winding down the old roots (phase four as described in the proposal) is going to be a long and slow process so I want to make sure we're making sure that while we're in the transition period that we've got an extremely clear picture on what's going on on both sets of roots. My problem with the Google "sliding scale" is that's its damn hard to understand when exactly a certificate is good or when it expires since the dates in the X509 certificate don't necessarily correspond with reality. By simply capping Symantec certificates to nine months, it puts us in a position that moving to a new DV/EV root would be required for them to remain competitive while not drastically affecting the ecosystem as a whole. Maybe I'm off-kilter here, but I think this proposal would help keep impact on WebPKI to a minimum but light a fairly serious fire to get users moved to the new root stores ASAP. Please let me know if I am seriously off base with my understanding of the situation or the technologies involved; WebPKI is a complicated thing to understand :) Michael
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
