On 13/05/2017 12:27, Michael Casadevall wrote:
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.
I suspect you may be believing too much of what Google says, see
specific problems below.
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.
This won't work for the *millions* of legitimate, not-misissued, end
certificates that were issued before Symantec began SCT embedding
(hopefully in the past) and haven't expired before such an early
deadline.
Also, since both Mozilla and Debian-derived systems such as Ubuntu use
the the Mozilla store as the basis for S/MIME checking, it is worth
noting that CT-logging of S/MIME end certs under the current Google-
dominated specifications is a guaranteed spam disaster, as it would
publish all the embedded e-mail addresses for easy harvesting.
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.
That is unfortunately true.
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).
However it would mandate that they be updated with new certificates
instead. A lot easier, but still a mountain not easily moved.
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.
I strongly believe the "9 month" rule mysteriously proposed but never
explained by Google was designed specifically to make buying certs from
Symantec all but worthless, chasing away all their customers. People
*paying* for certificates generally don't want to buy from anyone
selling in increments of less than 1 year, preferably 2 or 3. "9
months" is an especially bad duration, as it means the renewal dates
and number of renewals per fiscal year will fluctuate wildly from an
accounting perspective.
- 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
Are there any RA's left for Symantec?
- 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.
I believe the only reasonable interpretation of the "new root" plan
would be based on cross signing for trust by old Mozilla browsers and
other root programs.
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.
For starters, we can demand that Symantec never issues misdated
certificates lest they be thrown out instantly. So far the only
misdatings known were a very few that were well documented with very
good technical excuses.
Forcing the stand-up of new roots operated by competent management and
staff is indeed good, but to do that safely (i.e. without false
security theatrics and same old flaws) would require that Symantec
spends several months to get their house in order before generating
the new root keys.
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 :)
The fundamental questions are:
Should we light a fire under the sloppy Symantec management or under
their innocent users?
And should we allow enough of Symantec to keep standing to not leave
those users who cannot switch stranded with nowhere to go but a 404
webpage?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
