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 :)

Attachment: signature.asc
Description: OpenPGP digital signature

dev-security-policy mailing list

Reply via email to