On 15/05/2017 22:06, Michael Casadevall wrote:
On 05/15/2017 09:32 AM, Jakob Bohm wrote:
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.
Sorry, I could have been more clear here. What I'm proposing is that
after a specific TBD NotBefore date, we require SCTs to be in place on
the certificate to be trusted. Certificates from before that date
would remain trusted as-is (pending any reduction of expiration time).
Ok, that's much better.
I don't know if NSS has support for checking of SCTs (I can't pull the
source at the moment to check), but it should fail if the SCT is
missing, and otherwise behave like OCSP validation.
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.
I didn't consider the S/MIME use case here. A brief look at the root
store I'd be fine with the SCT restriction only applying when looking
at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata,
it looks like at least some of the current Verisign/Symantec roots
have both the S/MIME and server auth bits enabled.
While I feel CT would be a nice thing for S/MIME, unfortunately, I
have to agree with this point that we don't need to make spammers
lives easier. That being said, part of me wonders if there would be
other undisclosed intermediates if one could easily evaluate S/MIME
issuances ...
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.
See above on NotBefore.
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.
I can see the point here, but I'm not sure I agree. Every time we keep
digging, we keep finding more and more problems with these roots.
WebPKI depends on all certificates in the root store being
trustworthy, and Symantec as a whole has not exactly shown themselves
to be responsive or willing to communicate publicly on the various
issues brought up on the list.
Yes, that seems to be the trend. But it has nothing to do with if the
"9 month" rule or some other measures are the best remedy.
There's a decent argument to be had to simply disallow new issuance
from the existing roots and allow the current certificates to age out
(in which case imposing SCT embedded as I propose is simple), but I'm
not sure we've gotten a complete picture of how far this rabbit hole goe
s.
That wouldn't work, see below.
There's been a continual pattern of "this is everything", and then we
find another bunch of misissued certificates/undisclosed subCAs/etc.
Can we honestly say that we're comfortable with allowing these roots
to still be active at all?
- 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?
TBH, I'm not sure. I think Gervase asked for clarification on this
point, but its hard to keep track of who could issue as an RA. I know
quite a few got killed, but I'm not sure if there are any other subCAs
based off re-reading posts in this thread.
RAs (external companies that can decide if Symantec itself should issue
a cert) are completely different from external SubCAs (external
companies that have their own CA and a certificate chain back to a
Symantec root), which are different from internal SubCAs (CA
certificates for Symantec controlled keys, such as the SubCA that
signed normal OV certificates issued in January 2017).
External and Internal SubCAs can be blocked by simple technical means
via TrustDB and OneCRL manipulations. RAs are indistinguishable from
Symantec itself when checking certificates, because the certificates
were in fact signed by Symantec itself.
- 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.
Won't the cross signature though have to be embedded in Firefox, or
included in a server's SSL bundle for it to actually work?
Older Firefox/NSS won't have the whitelisting provisions in it, so
they'd accept the cross-signature if they're presented with it in the
certificate bundle.
I realize that as I write this though that this might be a technical
impossibility (or at least exceedingly painful) to do so that might
kill this part of my proposal as a matter of course.
The standard way this is done is that the old roots (which are trusted
by old browsers) cross-sign the new roots or the subCAs of the new
roots. People buying new certs get (as always) a new cert chain for
their new cert, which contains enough data to pass in browsers that
trust new root, trust the old root, or trust both roots.
Servers with old certs still return the old certificate chain that
leads to the old roots.
Other measures (such as browser embedded SubCA/cross certs) can be used
to reduce how much of the old CA tree Firefox/Thunderbird trust during
the transition.
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.
Which leaves us in the ugly situation of trusting roots which have
serious trust questions on it. I agree that any case of backdating to
evade a technical control is grounds for the CA death penalty
regardless of customer fallout.
Looking at the points you bring up though, I think we can deal with
the issue as a whole as long as CT is enforced, and that we can
independent confirm that enforcement via embedded SCT since frankly,
I'm not inclined to trust Symantec saying "yes, this is everything"
with regards to certificates they issued.
The fundamental questions are:
Should we light a fire under the sloppy Symantec management or
under their innocent users?
Honestly, part of me is thinking the only reason a full distrust is
not being discussed is because Symantec is "too big to fail" in the
WebPKI world. I don't like the idea of breaking end-users at all, but
I also dislike the idea of weaking trust in the PKI system simply
because the impact of doing something is too big.
On some level, I do think a fire has to be lit. We won't be stuck in
this situation otherwise. How big and how severe is TBDed
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?
Removing the EV trust bits at least has the effect of only making the
green bar go away. I think a large part of this comes down to the
question if the RAs could issue EV certificates or not which was still
pending last I checked.
However, going a step beyond that, EV represents that a CA has looked
in-depth to make sure a cert is going to the right person. For example
during the period the cross-signature to the federal PKI was in place,
any fPKI CA could have issued a certificate that would have been green
barred by Mozilla. I can't say with any confidence than any EV
certificate issued by Symantec as things stand actually has had that
check and balances.
I think we will need to look separately at two very different issues:
1. Symantec's PKI and the location of the EV trust bit unfortunately
allows non-EV SubCAs to issue EV certs that Firefox marks as green.
This same issue applies to most Mozilla trusted roots, because
Mozilla implemented the EV trust at the root CA level rather than at
a SubCA level.
This can be fixed technically by restricting the EV trust to the
SubCAs that are supposed to issue EV certs, rather than to whatever
general WebPKI root cert resides above it (in order for legitimate EV
certs to be trusted as normal certs by old browsers).
2. If there were any significant failures in the validation of EV
certs signed directly by the dedicated EV SubCAs at Symantec (other
than the one test cert that got some Symantec people fired some time
ago).
We might be able to limit the damage here if we could determine what
was checked by who, and scoping EV removal based on that, but I'm not
even sure we have a clear picture of who could sign with what at the
moment. Short of independently re-validating EVERY certificate, I
don't see a good solution for solving this though.
That's not great for Symantec's customers, but its also far better
than a broken website. It also lights a fairly huge fire on them to
get new roots spun, and then allow for reissues from the old roots to
the new.
My 2 cents,
Michael
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
