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

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.

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

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.

>> - 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.

> 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.

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,
dev-security-policy mailing list

Reply via email to