Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

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

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 

Re: [EXT] Re: Draft further questions for Symantec

[Michael Casadevall via dev-security-policy]

I took a stab at trying to grok this. I find I have more questions and a
lot more concerns the more I read though. Please let me know if I'm not
the only one having issues decoding the responses. Here's my first
impressions:

RA & EV:
Were all the certificates issued by the RAs uploaded to a CT log? If
not, what, if any, subsets were uploaded?

I'm aware Symantec was required to upload certificates to CT or if it
was retroactive, but I'm unsure if that requirement was extended to the RAs.

Furthermore, based on what I'm reading, at least one of these
certificates should be in the logs since it took place post 01/01/15.

Issue Y:
A simple yes or no answer for the questions would have been nice here.

What I'm reading and my understanding suggests that the subCA
certificates could have technically issued a certificate trusted by
Mozilla, but system controls prevented them from being used that way.
How these system controls work is at best unclear.

It's worth noting that the subCA "State of Florida AHCA Medium Assurance
CA" and several other fPKI subCAs chaining off "VeriSign Class 3 SSP
Intermediate CA - G2" are listed in crt.sh is listed as trusted in
Mozilla in crt.sh (https://crt.sh/?caid=1384), and based on my
understanding thus could theoretically issue certificates as there's no EKU.

I can't find any leaf certificates issued by these CAs in crt.sh to
confirm this fact though. Here's a question for Symantec, how are they
aware of what certificates these sub-subCAs have or have not issued?

I'm not sure if the green bar requires OIDs in all points along the
certificate chain or if this Florida CA could have issued an leaf
certificate by adding the OIDs there.

Issue L:
Given that the cross-signature was doing by VeriSign, I've got more
questions. As far as I can tell, the response suggests that Symantec was
aware that the cross-signature allowed the FPKI to be trusted in places
it otherwise wouldn't be, and decided to ignore it until it expired out
in 2016.

That sounds bad, but my other possible reading of this was: "We were
unaware of the cross-signature until 2014, and we let it expire in 2016
since we didn't know what it did".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/16/2017 11:10 AM, Peter Bowen wrote:
> Jakob,
> 
> What I think Ryan has been trying to express is his view that this
> request is not possible.  A *stable* data format is unable to
> express future graduated trust rules.
> 

I've been thinking on this and I'm starting to question this. The fact
of the matter is most of the graduated trust scenarios involve a
whitelist/blacklist, or putting restraints on the values of fields on
a certificate. If you simply have a way to express requirements for
ASN1 fields and such, that handles lot of the simple cases. For
example, wosign would need the following constraints:

"CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=C
N"
  blacklist-leafs:
- NotBefore: > 2016-21-10
- Attributes: inclusive

For the case of ANSSI, it would look something like this

*ANSSI Distinished Name*
 - blacklist-leafs
 - whitelist-leafs:
   - CommonName:
 - ends-in .fr
 - ends-in .gp
 - ends-in .gf
 - ends-in .mq
 - ends-in .re
etc.

For knocking out the future certificates, and that this blacklist
should apply if this certificate appears anywhere in the chain of trust.

While that won't handle every single case, being able to specify that
a field must be present, or have this valid (or not have this valid)
in an extensiable way would handle a fair number of cases for
graduated trust.

Granted, it won't handle everything, but it's not let perfect be the
enemy of good here. Right now, if you naively imported the Mozilla
root store, you get a number of certificates you probably shouldn't be
trusting.

In the case we need to specify a new type of trust restrictions, then
we extend the format, and implement it. It's up to downstream authors
to actually parse the data and do something with it. If the graduated
trust data is in a standardized format, there's a decent chance other
libraries may be willing to support it.

If someone can prove me wrong and show a case where Mozilla proposed
or implemented graduated trust that couldn't be expressed as a
combination of a whitelist/blacklist, and attribute comparsions, I'd
very much like to know if it.
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJZGzGOAAoJEHM+GkLSJHY5dTEP/iLWY9Wgeb8gvt/dY/Bp0BCA
QLX+/i3rv/TOm/plxL/tKrHg8pM7YDVwBHRR51i5vmko2712yVPlXbSAnnqyL3bV
IzSNgKUiMjbeLhO98P9pXH5M586VzAPnLrxilrjrvXZJRmL+nTdguDRBAPO1+6qe
La7WOpPgxVfaf2u+8e+waqjDF517VaAy2PaZAm5VP5EB+i50QqyGHJfwuTvArBeY
c28ZHXso5t1qze2dmKCvg4lIARwvckwTdx0dqiedcZSIm++wd8K0Yq+I85R0SH6g
gUv6LLf4b4JlQER0KQ3ozdqRhNwRd+VwReuGDTeE6PH9/2UCpIkt44BDLlfC+Jt5
Y+4lw3FTGgHDLdVaeLZqGVaE/47aQgmU3gdfAPRe0q47GBb3uqwSsfg4LBO7+lFQ
BAIGNOi3v2Zr/aALmtBCo0zzn+wt67OF4uIAFhhNTyP6o7XsWXJwSSwW0eO41mOe
QuSYx6ETNOh5u01uAR5+GSaOwNxKZBSYMyXBv3yAV9ZSrSD1aA17oRJFlClYkHyM
uhLPpn5TZ5Q25gtQiS8MvxiHqo6+joV9hAw/b0nNqkFAFzHI1OaZzy0p8bOmKI+d
/auRC56g5mGdOIY8h0fFgoFAfh/adohubqiGqMt0Yn9c9yB51OjM+JJ9XKGuAI3+
2+gZjY9o4tH+qCmVD/Va
=JEMo
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

On 05/16/2017 01:04 PM, Jakob Bohm wrote:
> 
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
> 
> 1. The date restrictions on WoSign-issued certificates.
> 
> 2. The EV trust bit for some CAs.
> 

Not the OP, but WoSign restrictions are hardcoded:
https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/NSSCertDBTrustDomain.cpp#741


EV OIDs live in PSM, and are hardcoded into the browser:
https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/ExtendedValidation.cpp

At least in the case of EV though, I'm not sure if anything beside the
browser itself actually cares EV vs. DV (or OV) in practice though.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
> If the key is compromised, you can't rely on any date information 
> anymore, you need to revoke it completely and break things.
> 

Won't that only be true in certificates without SCTs? Once you have a
SCT, you have an independent timestamp you can check beside the
NotBefore value, and can independently confirm since CT logs are
append-only.

(Granted, I realize nothing actually checks the SCT in this way to my
knowledge, but the idea itself may be on semi-solid ground).
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJZHDLHAAoJEHM+GkLSJHY5rnAP/A7Y7x0B5yr/t3ft5Ua4k5BP
P1EKD/Oguwf2QqTiBYgvuKOvdc8aCkOCoVXcq9awyERUzxpW/Pcvz5bOfLLyYY8v
qLLFTAXylJSJvFCSlw8+M1aiFEcTzeVptOUl51yQbBxxooWh4Oc8BrhvBZsCZqO3
j5KEWKo7kGLN0pAfocXDHBktb3DVJBnQnyakrUFooz0BgoH+cfJ2te/dSSSNspvw
TfPfydWC/ANg7FBkvuc4cZrH3PSGEfpnR7kcvFTfD56Pg2Q90i46gS3ikGdqHaA0
F3GOQ456J0sFpM3wjmIVvLV6OKnQG0jBNicrkyYOydw+YHTVwyhJN12VT7kAlYdc
HUVdl18T+Fx2waf/J8sQLyrYoE8QQ0nEZ+8DC4/XXe7gkxwxSFfvD8fUTLnYRI8F
TNfq1D+DnIQIQsEDEX5PYfgRAgNohKhzy6L+btLeyqLsqI1Vxak3cCJ40Zl68Pj8
NpTSvPchlSiUZNPRDD6moRIJdsSIfEGPDn6jjOntw4Go3gwg67jPl8btePBM3VWD
9WRAy6KGdX5rRWsrvH1Zrrmeqjsqe8kQ6t3vGbuU0Qcd7hDT4EoDWWTRafy8Nsbc
BIag3UXSWtF27LLpw/0C+6wPDT9krdl01JMTPwc0li0tYYL8h7W3FfHe8jMvnOmT
Z0bUn1hiBjaFftVpdlM0
=RWD4
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

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





signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

On 05/16/2017 06:05 AM, Peter Gutmann wrote:
> Ryan Sleevi via dev-security-policy  
> writes:
> 
> Unless someone has a means of managing frequent updates of the root
> infrastructure (and there isn't one, or at least none that work), this will
> never fly.  There's a reason why roots have 20-40 year lifetimes and why they
> get on-sold endlessly across different owners rather than simply being
> replaced when required.
> 
> Peter.
> 

Arguably, this would be a nice thing to fix since it could help reduce
issues with CA's changing owners. If we could update root stores
retroactively, it would make a lot of migrations simpler. For example,
if a device took the entire Mozilla root store before CNNIC was booted
out, those devices would still trust those certificates. Given the
glacier pace some things update at, having a type of root agility would
be rather desirable.

Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but certificates signed before that would still be valid for
that root, and then can be wound down beyond that point.

Maybe a bit out there, but an interesting thought none the less. It
would definitely go a good way at preventing one root certificate from
underpinning a large chunk of the internet. My thought here is if a
large "Too Big to Fail" CA's private key was
compromised/factored/physically stolen, our only recourse would be to
remove them from the root store, and deal with half the internet
breaking. Would be nice if that could not be a thing.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

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

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

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/16/2017 03:50 AM, Michael Casadevall wrote:
> On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>>
> 
>  - 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).
> 
>  - All server authentication certificates shall be submitted to at least
> two public CT logs.
> 

Just realized I had a brainfart when writing this. Don't believe I can
supersede on this list to fix it so sorry for the chatter.

This should say that certificates must be issued with an embedded SCT
which Symantec can get from their own log, and then upload the
certificate to other logs as part of the issuance.

As part of the CT validation, there would be a three day grace period
from the issuance date, to when the certificate can start failing due to
CT failure which should leave a nice bit of padding for the maximum
merge delay on the current public logs.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

Comments inline.

On 05/19/2017 05:10 PM, Jakob Bohm wrote:
> Suggested trivial changes relative to the proposal for Mozilla use:
> 
> 3. All non-expired Symantec issued certificates of any kind (including
> SubCAs and revoked certificates) shall be CT logged as modified by #4
> below.  All Symantec referenced OCSP responders shall return SCTs for
> all such certificates, if possible even for revoked certificates.  This
> also applies to expired certificates that were intended for use with
> validity extending timestamping, such as the code signing certificate
> issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f
> c9 71 67 0e 73 e3 69 c7 91.  Independent parties or root stores may at
> their option use this data to generate public trust whitelists.
> 
>   Necessity: Whitelists in various forms based on such CT log entries,
> as well as the SCTs in OCSP responses can provide an alternative for
> relying parties checking current certificates even if the cleanup at
> Symantec reveals a catastrophic breach during the past 20+ years.
> 
>   Proportionality: This should be relatively easy for the legitimate
> certificates issued by Symantec, since the underlying data is still
> used for OCSP response generation.
> 

Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to
be created at the time of issuance. Not sure if there's a way to
backdate this requirement. If this is only intended for the new roots
then just a point of clarification.

> 4. All stated requirements shall also apply to S/MIME certificates.



I *really* like this since it solves the problem of S/MIME + CT, but I
think this has to get codified into a specification. My second thought
here though is that there's no way to independently check if the CT logs
correspond to reality unless you have the public certificate since the
hashed fields would cause the signature to break.

I'd love to see this go somewhere but probably needs a fair bit of
thought and possible use of a different CT log vs. the primarily webPKI
ones.

> 
> 5. All stated requirements shall also apply to SubCA certificates other
> than the specially blessed "Managed CA" SubCAs.  These shall never be
> redacted.  As a special exception, the root programs may unanimously on
> a one-by-one bases authorize the signing of additional Managed SubCAs
> and/or new infrastructure cross certificates, subject to full
> validation and signing ceremonies.  The root programs will authorize
> enough new infrastructure cross signatures if and when they include the
> roots of the new infrastructure.
> 

Believe this was already covered by the PKI concerns that Symantec would
not be allowed to use third-party validation. Not sure if we can
realistically do a technical measure here since if we put a NotBefore
check in NSS, we have no easy way to change it in the future if it
becomes necessary for a one-off.

> 
> 6. All stated requirements except premature expiry and the prohibition
> against later issuance shall apply to delegated OCSP signing, CRL
> signing and other such revocation/validation related signatures made
> by the existing Symantec CAs and SubCAs, but after the first deadline
> (ultimo August), such shall only be used for the continued provision of
> revocation information, and shall have corresponding EKUs.  This
> corresponds to standard rules for dead CA certs, but adds CT logging of
> any delegated revocation signing certificates.  These shall never be
> redacted.
> 

I think this can be more easily put as "intermediate certificates
restricted via EKU for use for OCSP/CRL shall always be trusted for
purposes of maintain infrastructure". I don't think there's much risk of
a subCA that's limited to these roles to general webPKI unless such a
certificate was used to misissue a CRL that blacklisted all of
Symantec's certificates (which wouldn't be our problem per say).

> 
> 7. All stated requirements except the premature expiry shall apply to
> time stamping signatures and certificates for timestamps 
> 8. As Mozilla products don't currently trust any code or object
> signing certificates
> 9. Symantec shall be allowed and obliged to continue operation of the
> special "managed signing" services

Can't help but feel that this is out of scope; Mozilla only cares about
emailProtection and serverAuth EKU bits. A few CAs still have code
signing bits in NSS due to historic reasons but Mozilla isn't a
code-signing root store.

What other root stores (especially those not related to WebPKI) is not
our business.

> 10. Symantec shall be allowed for marketing purposes ...

I'm hesitant on this one because this requirement seems overly broad and
out of line with current practice. Going to leave it for other people to
poke at.

Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

On 05/19/2017 05:43 PM, Kurt Roeckx wrote:
> So I think we have a few categories of certificates:
> - Those issued in the past, which can still be valid for up to 3
>   years. I'm not sure when the last 5 year certificates are
>   supposed to expire, or if they all expired, but I don't think
>   those take long to expire.
> - Those that still get issued before they move to some new PKI.
> 
> If you want to distrust their existing roots before those
> certificates expire, this will most likely results in at least
> some people having problems. And that it would be up to Symantec
> to make sure those people get new certificates and started using
> them.
> 

When it boils down to that, I'm OK with the existing certs being allowed
to age out (perhaps capped to 39 months total if there are any five year
certificates still floating around) as long as new issuances are stopped
from the old roots within a reasonable time frame.

That being said, new issuances from the existing PKI should be capped on
expiration.

>>From the mail about Chrome's plan, I understand that Chrome's plan
> is to only allow certificates from the old PKI if they qualify for
> their CT requirements. They plan to only allow certificates issued
> after 2016-06-01 because that's the date when they required CT
> from Symantec. It seems that Symantec can still issue new certificates
> using the old PKI up to 2017-08-08 that are still valid for 3
> years.
> 
> I'm a little concerned that Firefox and Chrome will have different
> certificates they don't trust, and would hope that you can come to
> some agreement about when which one would get distrusted.
> 

This was likely unavoidable due to the simple fact that the
Google-Symantec discussions happened behind closed doors. Unless we can
influence Google's final policy, then this is likely going to be the
case no matter what.

> I have a problem with one CA signing an other unrelated CA. I
> would prefer that we have a policy that forbids that, and that the
> CA should make sure it's own root gets added to the root store.
> The only reason I can see for cross signing is for people that still
> using an old root store.
> 

++ here

>> - I'm not sold on the idea of requiring Symantec to use third-party CAs to 
>> perform validation/issuance on Symantec's behalf. The most serious concerns 
>> that I have with Symantec's old PKI is with their third-party subCAs and 
>> third-party RAs. I don't have particular concern about Symantec doing the 
>> validation/issuance in-house. So, I think it would be better/safer for 
>> Symantec to staff up to do the validation/re-validation in-house rather than 
>> using third parties. If the concern is about regaining trust, then add 
>> auditing to this.
> 

The current proposal is more complicated than that since it talks about
reusing part of the original validations and OIDs to control the max
length of the certificate. I rather dislike that since its both complex,
and introduces the trust issues from the old hierarchy into the new one
which moots the point of spinning up a new root in the first place.

> So they should just create new root CAs and ask them to be
> included in the root store?
> 

Honestly, we got into this mess in the first place due to third-party
signers. I don't think the right solution to stopping a gas fire is to
throw more gas on it.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/19/2017 10:25 AM, Gervase Markham wrote:
> Embedding SCTs is not the only way SCTs can be delivered - they can come
> in the SSL handshake or via OCSP. Requiring them to be embedded does
> have the advantage that certificates now carry an unforgeable timestamp,
> and it was something I proposed in a version of Mozilla's now-dormant CT
> policy. But for various reasons, it's not necessarily practical to
> require it in all circumstances (which is why the CT RFC defines
> multiple mechanisms).
> 
> Firefox does have some support for checking SCT presence and validity,
> but it's not turned on.
> 

My concern here is right now, we're trying to rebuild trust for
Symantec. We're very much in a "trust but verify" sorta thing, and I
don't think it's an unjustified requirement to do so. I think CT is
about the only thing that has allowed us to reasonably consider keeping
Symantec in the root store at all.

However, for Mozilla's purposes, is there a case where having a SCT in
certificate would either break something, or otherwise be undesirable?

Well, at least with the current state of webpki, mandating an embedded
SCT is probably not practical for everyone. I actually forgot about the
OCSP stapling mechanism for SCTs, though my concern here is not everyone
turns on OCSP stapling. Since both OCSP CT stapling and embedded SCTs
require that the cert be submitting to a log at issuance, part of me
wonders if the right middle ground is this:

As far as I know, I think Microsoft's IIS is the only major web server
that turns OCSP stapling on out of the box.

 - By default, Symantec shall issue certificates with embedded SCTs
(soft-fail for failure to validate SCT information)

 - If, due to customer demand, a certificate with an embedded SCT can
not be used, said certificate must get the SCT information by a stapled
OCSP response or via TLS extension to be trusted by Mozilla. (hard-fail)

This should cover the general case fairly well, and for the edge cases,
well either its for a special class of device that we don't care about,
or the customer has to do some work to get things working in Mozilla.

Or in other words, if there's a case where an embedded SCT can't fly
here, then we mandate that one of the other two validation options must
be present for things to fly. That being said, for my personal
knowledge, I'd love to know more on the real world practicalities of
embedding SCTs.

Thanks for your feedback.

>>> Are there any RA's left for Symantec?

Following up to this, the question that I should have asked is who can
technically do an issuance of certificates based on Symantec's roots.
SSP customers are a recent discovery. I wonder if there's anything else.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

On 05/16/2017 08:40 AM, Rob Stradling wrote:
> On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
> 
>> Just spitballing ideas here, but in Alex's case, part of me would be
>> tempted to see if X509 could be extended with a new "CanIssueUntil"
>> field. Basically, it would act as an off switch for CA:TRUE after a
>> given date, but certificates signed before that would still be valid for
>> that root, and then can be wound down beyond that point.
> 
> That sounds like the "Private Key Usage Period" extension, which was
> present in RFC3280 but removed in RFC5280.
> 
> https://tools.ietf.org/html/rfc3280#section-4.2.1.4
> 

I learned something new today. I'm about to run out the door right now
so I can't read the RFCs but do you know off the top of your head why
that was removed?
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[Michael Casadevall via dev-security-policy]

On 05/21/2017 02:37 PM, userwithuid wrote:
> To me, the most noticable difference between how Google and Mozilla can take 
> action is with regards to exisiting certs. As proposed, Google has a really 
> neat timeline to get rid of Symantec's questionable legacy stuff quickly and 
> effectively. (Legacy stuff which we - and arguably Symantec themselves 
> judging from their responses on here so far - still don't have a complete 
> picture of).
> 

There's also a fair number of points dealing with who can sign and for
what while Symantec spins up the new roots (which the Google proposal
says a trusted third party CA signed by Symantec").

I'm against this point specifically because third-party CA operations is
how we got into this mess. I rather cap new certificate length from the
existing roots as both a way to light a fire under Symantec and to avoid
the same old mistakes.
Michael

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fond Farewell to Gerv Markham

[Michael Casadevall via dev-security-policy]

While I didn't know Gerv personally, I always respected his insight and 
knowledge I've gotten from years lurking on this list. He will be missed :/


Michael


On 07/29/2018 12:23 PM, Kathleen Wilson via dev-security-policy wrote:

Dear Fellow Mozillians,

It is with deep sorrow that we share the news that our friend and 
colleague, Gerv Markham, passed away on July 27, 2018. Along with the 
many others whom he worked alongside over his time at Mozilla, we will 
remember Gerv as caring, honest, inquisitive, opinionated, energetic, 
and a lot of fun to work with! He enjoyed and looked forward to 
meeting with people in person, and loved diving into the details. He 
was often the first to pick up the phone to talk to people to get to 
the core of a situation. He was also quick to be helpful, going out of 
his way to provide assistance where needed. He would identify things 
that were in need of repair, meet with the owners to find out if they 
needed help, and dive right in to do the work.


Previously from Gerv: “It's been eighteen years since I first entered 
the world of Mozilla, on a program of constructing reduced layout test 
cases for early Gecko builds in order to earn a dino plushie (I got 
two!). Both I and the project have come a long way since then, but an 
ever-present companion has been my cancer, with which I was diagnosed 
in 2001.”


Eighteen years is a remarkable length of time to fight against 
incurable illness, and we are proud for the fighting Gerv managed to 
do throughout those years to advance Mozilla's mission.


Over the years of Gerv’s tenure with Mozilla, he worked on public 
policy, certificate authority (CA) root program, community governance, 
MPL, licensing, usability, security, and Bugzilla. He attended every 
CA/Browser Forum face-to-face meeting that he could, and the 
CA/Browser Forum extended the attached commendation to him.


It has been an honor to work with Gerv, and it is with very fond 
memories that we say goodbye to our wonderful friend and colleague, 
Gerv Markham.


Fond Farewell,

Kathleen Wilson, Wayne Thayer, JC Jones, and Chris Riley (among many 
more)



PS: Here is the text from the CA/Browser Forum Commendation that is 
mentioned above.

~~
The CA/Browser Forum and its members gratefully extend to Gervase 
Markham their heartfelt commendation and appreciation
For his extraordinary leadership and skill as a founding member of the 
Forum in 2005 and as a Mozilla representative and a leading Forum 
participant from 2005–2018, and
For his superb work in promoting higher standards for Certification 
Authorities, and
For his ceaseless efforts to improve security for users on the 
internet, and
For sharing his deep knowledge of TLS and PKI with his fellow Forum 
members, and
For his constant innovation and improvement to the Mozilla processes 
applicable to CAs around the world, and
For his skills during Forum meetings and teleconferences so that all 
could participate on an equal basis and members’ time was well spent, and
For his ability to bridge differences of opinion among members to 
reach solutions that could be supported by all, and
For his tact and diplomacy in helping Certification Authorities and 
Browsers meet their mutual goals, and
For his patience, wit, sincerity, honesty, pleasant demeanor, and 
everlasting good cheer, and

For his superior guidance, advice, and management style.
-- For these and many other accomplishments we hereby affirm our deep 
appreciation, commendation, and congratulations to Gerv, and sincerely 
extend our best wishes to him and his family. --

Dated this 22nd day of March, 2018.
ADOPTED UNANIMOUSLY BY THE MEMBERS OF THE CA / BROWSER FORUM
~~
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DEFCON Talk - Lost and Found Certificates

[Michael Casadevall via dev-security-policy]

On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote:
> On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> It seems that my response to this presentation has brought out the crowd
>> of people who are constantly looking to reduce the usefulness of
>> certificates to anyone but the largest mega-corporations.
>>
>> To summarize my problem with this:
>>
>>   - While some large IT operations (and a minority of small ones) run
>>fully automated setups that can trivially handle replacing
>>certificates many times per year, many other certificate holders treat
>>certificate replacement as a rare event that involves a lot of manual
>>labor.  Shortening the maximum duration of certificates down to Let's
>>encrypt levels will be a massive burden in terms of wasted man-hours
>>accumulated over millions (billions?) of organizations having to do 4
>>times a year what they used to do every two or five years.
>>
> 
> The trend is away from manual replacement, not towards it -- and that's
> true for individual people, for large enterprises, and for smaller
> companies in between. For individuals and smaller enterprises, this
> manifests mostly in the increasing outsourcing of certificate management to
> third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager,
> etc.).
> 

In my limited experience, this trend is *because* of Let's Encrypt
getting them to do it four times a year. A lot of my freelance work has
been automated certificate rollovers due to cost, and usually some
fiddling every X months when a domain fails to validate and the
certificate fails to issue. For a lot of places, the time spent having
someone automating it offsets the annual cost of having to fork up for a
certificate (or getting management to approve an expense)

It should be also noted that I've seen quite a few organizations decide
the cost of automation is too difficult or the systems using the
certificates are too fragile and rather pay for longer lasting
certificates.

> For larger enterprises, the same outsourcing is also present and is
> mitigating manual rotation burdens, but some are also investing in their
> own systems for automation inside their environments. I've seen several
> spring up in enterprise environments I'm close to in the last few years in
> order to handle the increasing pressure to secure connections by default
> even when the certificate volume is high.
>> Reducing certificate lifetimes to 13 months, in addition to addressing
the> real security issue identified by the Lost and Found Certificates
> presentation, is likely to further these trends, which would be a positive
> development both for user security and enterprise agility.
> 
>   - While infinitely wealthy organizations can afford getting separate
>>certificates for each DNS name, and while lowest-security (DV)
>>certificates are now available for zero dollars in the US, SANs remain
>>significant in case of high security validation (OV, EV) that costs
>>real money and effort, both to pay the CA and to provide evidence of
>>human and organizational genuineness, such as showing government IDs,
>>obtaining certified copies of registration statements, answering
>>validation phone calls to CEOs at strange hours etc.
>
SANs are also important in DV certificates unless we're talking about
wildcards. Lets Encrypt certificates use the first domain as the CN, and
then all the subdomains as SANs. Given that wildcard certificates can be
undesirable, there are more than a few valid reasons to have SANs, even
in cases where everything is within one domain.

My largest problem with long lived certificates is that expiration is
essentially the only effective mechanism of removing old certificates
from circulation. Revocation at best is iffy, and down right broken
depending on who you ask between Chrome's CRLSets, OCSP Soft Fail, etc.

If we could fix revocation so it could work effectively, longer lived
certificates would be less of a risk factor.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Discovering unlogged certificates in internet-wide scans

[Michael Casadevall via dev-security-policy]

On 03/31/2018 09:53 PM, Tim Smith wrote:
> On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> Thanks for taking a look. My understanding of Rapid7's methodology [1,
> 2] is that they knock on well-known ports. The services they emit data
> for are pop3/s (110, 995), nntps (563), mqtt (8833), ftps (990),
> smtp/s (25, 465, 587), and imap/s (143, 990).
>
> I consumed their published data set and didn't perform any scanning
myself.
>

Ah, I misread, I thought you had done the scanning directly. Still, it
was good to take a look at this, and I'm looking through Rapid7's docs
on how to play with the data set myself.

>> When you say roots included to Mozilla trust store, how was this used
>> exactly? I see you used X509Validator, but did you just throw all the
>> NSS PEMs or did you remove the ones that are technically constrained?
>
> I used the certifi distribution [3], which is aware of "included but
> distrusted" [4]. The certificates were "validated" naively without
> considering e.g. path length or name constraints; certificates failing
> those constraints would certainly be interesting but hopefully rare.
>

Hrm, I might have a weekend project here. I've always been curious to
what extent technical constraints actually affected things. I may need
to download their data set and play with it somewhat.

>> I'd also be interested in see or graph that shows how many
>> certificates chain up to a given root.
>
> Sure; would you like to see that because it would help sanity-check
> the data, or because it might reveal differences vs. certificates used
> for HTTPS, or some other reason?
>

Partially for non-HTTPS usage, but I also wanted to see the
cross-section of how much "diversity" there was in how much of the
internet chains of a specific root certificate.

Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Discovering unlogged certificates in internet-wide scans

[Michael Casadevall via dev-security-policy]

On 03/31/2018 06:14 PM, Tim Smith via dev-security-policy wrote:
> Hi MDSP,
> 
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> which captures certificates from their scans of non-HTTPS ports for
> TLS-speaking services.
> 

Pretty interesting read, and always happy to see more information go
into CT. One thing I couldn't divine from your data was how did you look
for non-HTTPS services? Did you port scan and do service discovery, or
did you simply knock on well known ports that either are SSL by default
or support a STARTTLS equivalent?

If so, which well known ports were knocked on?

> I wrote up some findings at
> http://blog.tim-smith.us/2018/03/moressl-spelunking/.
> 
> A few highlights include:
> - of the ~10 million certificates in the corpus, about 20% had valid
> signatures and chained to roots included in the Mozilla trust store
> - about 50,000 of the 2 million trusted certificates had not previously
> been logged
> - about half of the novel certificates were unexpired
> 

When you say roots included to Mozilla trust store, how was this used
exactly? I see you used X509Validator, but did you just throw all the
NSS PEMs or did you remove the ones that are technically constrained?
(i.e., CNNIC is distrusted for new certificates, but is in the root
store for existing certificates before technical restrictions were applied)

This could influence the number of valid or invalid certificates you
saw. I'd also be interested in see or graph that shows how many
certificates chain up to a given root.

I do wonder if there would be value in a tool that basically takes a
x509 certificate in, and then runs it through NSS to determine validity
applying all technical constraints upon the way. I might have to fiddle
with NSS to see how hard it is to get at that functionality.

> There were interesting examples of unexpired, non-compliant, trusted
> certificates chaining to issuers including GoDaddy, NetLock, Logius, and
> Entrust. (I have not taken any action to inform issuers of these findings,
> other than this message and by publishing the certificates to CT logs.)
> 

Given all these certificates are new to CT, I'm guessing none of them
have come up before on MDSP.

Thanks for your effort,
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Michael Casadevall via dev-security-policy]

I appreciate the ground work Fabio put into this thus far, and want to
see further discussion on it.

I think the safest way to quantity and frame the discussion is asking if
a CA (or subCA) has a vested interest in surveillance, other business
interest, or government ties which would put a CA to be more likely to
abuse the trust, or has a history of business practices related to
surveillance or practices against the public interest in regards to WebPKI.

I recognize the points Scott brought up, but trust is always a
subjective thing. As previously pointed out, Mozilla has always retained
the ability to choose what to include or disallow based on community
input, and this entire thread shows there is a lot of community input here.

The problem with auditing in general is its only going to catch
information that is logged and archived in a corporation. It's an
assurance step but in and of itself is not enough to establish trust; it
not uncommon for misissues and other issues to be noted by the community
from information in the wild
Michael

On 7/10/19 3:59 AM, fabio.pietrosanti--- via dev-security-policy wrote:
> I understand the Nadim points, there's a lot of subjective biased "popular 
> judgement".
> 
> While from a security standpoint perspective "better safe than sorry" is a 
> good statement, from a rights and fairness perspective that's a very bad.
> 
> So further conversation is needed.
> 
> Following DarkMatter removal i would love to bring to the attention of 
> Mozilla the removal of a list of Companies that does as a main business other 
> stuff, but also does offensive security and surveillance with public 
> "credible evidences" .
> 
> I've analysed Intermediate CA list where DarkMatter is here 
> https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts .
> 
> In this list is possible to find the following company operating against 
> "people's safety" and there's "credible evidences" they are doing so:
> 
> 
> * Saudi Telecom Company
> 
> This company is publicly known to ask to surveil and intercept people as per 
> "credible evidences" on:
> https://moxie.org/blog/saudi-surveillance/
> https://citizenlab.ca/2014/06/backdoor-hacking-teams-tradecraft-android-implant/
> 
> 
> * German Rohde & Schwarz
> 
> This company do produce, install and support surveillance systems for 
> intelligence agencies in Regimes such as Turkmenistan:
> https://www.rferl.org/a/german-tech-firm-s-turkmen-ties-trigger-surveillance-concerns/29759911.html
> 
> They sell solutions to intelligence agencies such as IMSI Catchers and 
> massive internet surveillance tools:
> https://www.rohde-schwarz.com/en/solutions/aerospace-defense-security/overview/aerospace-defense-overview_229832.html
> 
> 
> * US "Computer Sciences Corporation"
> 
> The CSC is a US Intelligence and Defense Contractors that does CNE (Computer 
> Network Exploitation) like the WikiLeaks ICWatch show out
> 
> Read the profile of a former employee of CSC, doing CNE like Snowden was 
> doing:
> https://icwatch.wikileaks.org/docs/rLynnette-Jackson932c7871cb1e83f3%3Fsp=0ComputerSciencesCorporationCyberSecurityAnalystSystemsEngineerRemoteSystemAdministrator2008-09-01icwatch_indeed
> 
> Additionally from their wikipedia they acknowledge working for US Intel:
> https://en.wikipedia.org/wiki/Computer_Sciences_Corporation
> 
> CSC provided services to the United States Department of Defense,[23] law 
> enforcement and intelligence agencies (FBI,[24] CIA, Homeland Security[23]), 
> aeronautics and aerospace agencies (NASA). In 2012, U.S. federal contracts 
> accounted for 36% of CSC total revenue.[25]
> 
> 
> * Australia's Attorney-General's Department
> 
> The Australia's Attorney-General's Department is a government agencies that 
> wants to permit the Australian Security Intelligence Organisation (ASIO) to 
> hack IT systems belonging to non-involved, non-targeted parties.
> 
> It operate against people safety and there's credible evidence of their 
> behaviour in supporting ASIO to hack people, so they are very likely to abuse 
> their intermediate CA:
> http://www.h-online.com/security/news/item/Australian-secret-services-to-get-licence-to-hack-1784139.html
> 
> 
> * US "National Geospatial-Intelligence Agency" https://www.nga.mil
> 
> The NGA is a US Military Intelligence Agency, equivalent to NSA, but 
> operating on space GEOINT and SIGINT in serving intelligence and defense US 
> agencies.
> 
> NGA is the Space partner of NSA:
> https://www.nsa.gov/news-features/press-room/Article/1635467/joint-document-highlights-nga-and-nsa-collaboration/
> 
> I think that no-one would object to shutdown an NSA operated Intermediate CA, 
> i am wondering if Mozilla would consider this removal.
> 
> 
> Said that, given the approach that has been following with DarkMatter about 
> "credible evidence" and "people safety" principles, i would strongly argue 
> that Mozilla should take action against the subject previously documented.
> 
> I will open a