On 02/09/2016 12:19, Gervase Markham wrote:
On 31/08/16 20:43, Nick Lamb wrote:
This suggests the need for some options short of distrust which can
be deployed instead, but Mozilla does not seem to have any. If in
fact it already does, this would be a great place to say what they
are and discuss why they haven't been able to be used in recent
cases.
Have you considered what was done for CNNIC? In that case, we distrusted
all certificates issued after a certain time. We used a whitelist for
determining this, but it would be possible to use the notBefore date in
the certificate. A CA could dodge this by backdating, but if the CA were
also committed to putting all its certs in to CT, then the backdating
would be noticeable.
If the fraudulently backdated certificates are done (technically)
right, they would have serial numbers consistent with their old date
and would have non-CT logging also consistent with that old date.
Thus the only way to detect that those certificates were not in fact
issued before the cut off date would be to check against an independent
white list of actual pre-cut-off certificates. (Longer recipe at end
of this post).
1. Implement "Require SCTs" for problematic CAs. Notify the CA they
are obliged to CT log all certificates, inform subscribers etc. or
their subscriber's certificates will suddenly be invalid in Firefox
from some future date.
This is not currently possible in Firefox, as Firefox does not have the
ability to check SCTs. We hope to have that ability soon.
2. Create "at risk" category for problematic CAs which lasts some
finite period of time (or a period to be set in each case). Notify
the CA they are obliged to warn their subscribers of this status or
leave the Mozilla programme immediately. Publicly announce "at risk"
status and drive as PR.
One issue to consider with this option would be that reputational damage
is harder to quantify and control than a technical measure, which might
be said to increase the risk that the action would be disproportionate.
3. Split NSS trust store into two or more categories based on degree
of trustworthiness. Maybe present a Firefox pref to pick "secure" vs
"compatible"
Non-starter, I'm afraid. We are not loading this problem on to users.
Finally, I would like to mention, though I expect it to be shot down,
a much more radical way forward. RP audits. Relying Party audits.
Some issues to consider with this approach would be:
* How does the money to pay for such audits flow from the CA to the
auditor, and through whom?
CA must deposit the standard audit fee (non-negotiable, no race to the
bottom) in a standard bank escrow account releasable by the body that
chooses the auditors.
* Who chooses the auditors?
Obviously not the CA, and since there is no appropriate neutral
democratic body to do this (the UN GA would be overdoing it, ITU and
ICANN are having their own trust issues) maybe an ad hoc body
consisting of the CA/B forum plus extra representatives from relevant
groups such as the EFF, Transparency International, whatever
international organization acts as a union of Auditors.
* How do you make sure they remain independent when their funding is
(even indirectly) from the CAs?
Their fee structure and election is done by someone other than the CA,
who also hires and fires them on an annual basis, so they would be
fiscally beholden to that other body, not the CA. For example the
fixed price for a 2017 audit could be $xxxxxx per site per CA
organisation + $yyyyy per root cert + $zzzzz per intermediary cert +
$ccccc per million end certs. Amount to be deposited in an independent
bank at least 2 weeks before the audit is due to begin and releasable
only by signatures from the appointing body.
* How do you deal with confidentiality issues? CAs have some things they
legitimately wish to keep confidential. And yet such an auditor would
need full access to all their infra and business processes.
This is standard for properly certified auditors to handle, as long as
they are not completely chosen by a competitor or spy agency. This is
standard auditing practice with appropriate confidentiality obligations
often codified by law.
* Is it a problem that adding additional costs to becoming a CA
discourages new and possibly innovative companies from entering the market?
This cost (though maybe higher than the fee for a rubber stamp auditor)
would replace, not add to, the cost of a CA hired compliance auditor.
+++++
If a list of grandfathered WoSign (or some other big failed CA) issued
certs is too big to download to every client (in the browser
installer or in any other way), one practical solution could be this:
(Sorry, this is going to be a long recipe):
1. Copy all the grandfathered certificates in DER form to a secure
database at Mozilla HQ, a Beijing government agency or some other
strong location.
2. Generate a Merkle hash tree (using SHA-512 or better) of the
certificates in this original database and publish the top level hash
far and wide for public checking that no further changes will be made
by the custodian of this database. Methods to access the database
and check against the published Merkle tree can be done later, adding
or removing certificates after the top hash was published is
cryptographically "impossible".
3. Compute a more size-friendly SHA-256 of each DER encoded certificate
to remain trusted. Sort this list of SHA-256 values
lexicographically by their byte values.
4. Split the list according to the first m bits, the number (m) of bits
should be chosen so: The shortest partial list contains at least
1,0000 (ten thousand) certificates, the largest less than 10,0000 if
possible.
5. Place each list part in its own signed .jar file (to get the
compression and reuse the jar signature checking code) and name it
after the leading bits that are common for that file. Also create
.jar files with empty (0 byte) lists for any values of the leading m
bits that have no certificates. For example WOSIG-A1C.jar would
contain the sole file WOSIG-A1C.dat which is simply a sorted list of
binary SHA-256 values whose first 10 bits are all 1010 0001 11. It
would also contain some kind of expiration date indication.
6. Put these jar files on one or more https CDNs for public download,
for example, the URL for WOSIG-A1C.jar could be
https://foo.mozcdn.org/certwhit/WOSIG-A1C.jar
7. In the relying party configuration data, add an internal list of
certificates that have had this treatment, the hash alg (SHA-256),
the split bit count (e.g. m=10 bits), the authorized .jar signer
identity and the base URL (e.g.
https://foo.mozcdn.org/certwhit/WOSIG-).
8. In the relying party software (NSS) add code to interpret the above
list and download the fraction .jar file when an affected certificate
is seen, then check if the received certificate is in the list.
Because each .jar download covers at least 1,0000 unrelated
certificates selected pseudorandomly, it reveals little of privacy
concern (unless an invalid certificate from a rarely downloaded
bundle is injected into a connection while monitoring who downloads
that file, hence the use of a https CDN).
9. As TLS certificates are replaced, revoked etc. the .jar files are
regenerated and signed again. E-mail and object signing
certificates are not removed from the lists because those signed
e-mails need to remain checkable at a later time, regardless if the
original signer cooperates or tries to repudiate his own signature.
Once the last TLS certificate is gone from the list, the expiry
period of the .jar files is increased significantly, as there would
be few if any future changes.
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
