On 05/15/2017 06:05 PM, Jakob Bohm wrote:
> Ok, that's much better.

Yay for reasonable courses of action. We'll see if it goes into the next

>> 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 might be a reasonable compromise here, see below.

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

I thought the RAs were being issued off their own intermediate branches
and not off Symantec ones. Rechecking crt.sh "C=KR, O=CrossCert,
OU=AccreditedCA, CN=CrossCert Class 1 Server CA" is a separate
intermediate chaining to KISA so I done goofed here. Oops.

Re-reading the issues, I think I got crossed between subCAs missing
audits, and RA issuance.

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

Thanks for clearing this up.

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

This is a start.

We'd need confirmation from Symantec which subCAs are supposed to be
able to sign EV as I don't believe we have a complete list. That's also
assuming that things are that nice and organized (which is far from a
given). If we can successfully cut a good chunk of the crud away, it
would at least help in mind keeping EV being a reasonable option.

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

Can we reasonably determine we're good here beyond a reasonable doubt?

The current responses to the last question found new parts of the fPKI
that are chaining via the Issue Y intermediates that appear that they
would be trusted by Mozilla. We also have confirmation that some of the
RAs could issue EVs and could validate certificates.

Symantec said that they independently checked the non-expired EV
certificates, but I think I have (IMHO) justified concerns there might
be additional ones here we don't know about.

Given the number of unknown knows with the EV situation right now, I
think I'm going to wait for more information before pushing any one
specific option, but at a minimium, we need to cut down the parts of the
tree that can sign for EV.

There's also a third issue is "what is the correct response to the
severity of Symantec's trust issues". We're fairly close to CNNIC
territory here, since we've got multiple intermediates that chain to the
Mozilla roots and can issue certificates which are either not BR
compliant, or out of scope of an audit.

In an attempt to try and get this thread to a point where the powers
that be might choose to include it in their proposal, let's try the
following in the addition to what is under PKI concerns in the gdoc:

 - For any Symantec-owned root certificate in the Mozilla trust program
with the CKA_TRUST_SERVER_AUTH bit enabled, all leaf certificates in the
chain shall contain embedded SCT information. This shall be required for
the certificate to be trusted.

(or in plain English: web certificates need both CT and SCT embedded.
S/MIME certificates are alright without. We separate these into two
separate chains of trust so they can't accidentally intermix.).

 - For the purposes of CKA_TRUST_EMAIL_PROTECTION, all CA and subCA
certificates in the chain of trust must have embedded SCT information to
be considered trusted. The leaf certificate shall be exempt from this

 - A three-day grace period shall be in place from the issuance date of
a certificate to when it must be in the CT logs for validation reasons
(this is in line with other proposals here).

 - Certificates issued for server authentication without SCT information
being timely submitted shall be considered equivalent to a misissue.
Exceptions to this policy for legacy customers may be granted on a
case-by-case basis.

 - All server authentication certificates shall be submitted to at least
two public CT logs.

 - Certificates issued before the effective date shall continue to be
trusted until their expiration/revocation. These certificates shall be
exempt from the embedded SCT requirement unless reissued.

 - Symantec shall identify (if possible) subCAs are supposed to be used
for issuing EV certificates. The EV trust bit shall be removed from the
root, and added to the intermediate certificates.

 - Certificates issued from the pre-existing roots after the effective
date shall be limited to a maximum lifetime of nine months.


This revised proposal achieves the following
 - Mozilla never trusts a certificate we can't independently audit and
verify via the CT logs. This also slams the door shut on Issue Y of ever
becoming an issue again since we'd immediately be able to spot it before
the issue snowballs.

 - S/MIME and ServerAuth is clearly separated. No chance of a nasty
surprise from an undisclosed CA that has only been issuing S/MIME
certificates but could issue for SA due to a lack of EKUs (since S/MIME
intermediates wouldn't show up in the CT logs as far as I know).

 - In the S/MIME case, while we can't drop the entire load into CT to
find undisclosed intermediate certificates, we can mandate that the
embedded SCT for those subCAs has to be there. That should force all the
intermediate certificates that can sign for S/MIME into the logs so we
can at least get *some* idea of the situation here. It at least helps to
ensure that S/MIME intermediates are being disclosed, and we're only
trusting what is being disclosed. I don't know if we can reasonably do
this for the old roots though short of hardcoding all the SCTs into NSS
which is likely undesirable.

 - The SCT exemption policy allows for legacy customers to get
certificates for devices that might choke on them (since I've seen some
pretty ugly embedded TLS stacks). We will never trust a certificate
meant for this scenario, keeping in line with the above.

 - The old root certificates can't issue for longer that nine months
past the effective date. That should light a serious fire to migrate
ASAP, but prevent existing certificates from being heavily impacted
except in the case of reissue (which should be reissued against the new

 - For customers who pinned the old roots or can't migrate, issuance off
the old certificates remain possible while lighting a fire under them to
fix their infrastructure if they don't wish to reissue every nine months.

 - It at least limits some of the potential issues with the current EV
mess. I'm still personally of the opinion that this might need to go
further but at least its a start.

Final thoughts:
As far as I can tell and based on my reading, Mozilla products only care
trust bits being legacy. For CLIENT_AUTH, it might be worth doing
something similar to the S/MIME provision, but I don't know enough to
determine the actual impact here.

While I think there's still discussion to be had on max life+EV, I think
the mandated SCT provisions would go a *long* way in helping restoring
trust in Symantec since it means any potential misissues could be
detected relatively easily, and we never trust anything that can't be
independently verified.

It also goes a good way at lighting the necessary fires under Symantec
management, though some part of me wonders if the max expiration should
be lower.

I realize this might be a fairly large technical burden to get
implemented, so I'm willing to pitch in some way to help if someone is
willing to mentor me.

As always, hoping to hear comments, and the TPTB are willing to consider
it and point out where I've been stupid.
dev-security-policy mailing list

Reply via email to