Hi all,
(replying for myself, not any organisation.)
I wasn't aware of this debate, but now that it is closed, maybe it is
helpful to put some context on it.
The essential decision you have to take, and have taken is this:
Follow Mozilla's lead, or not?
Having taken it, I can say two things.
Firstly, that this is probably what you have to do: follow Mozilla's lead.
> Realistically I cannot vouch for any of the CAs we ship. That's one
> reason why we push that responsibility upstream to e.g. the Debian
> project or Mozilla.
In economic terms, the Linux distros don't really have the capability to
duplicate the work that goes on behind the scenes, the work to analyse
the choices, and the work to build some sort of cohesive policy in
analysing CAs. And nobody else has a similar project (I don't say open
project) to follow.
Your choice is only Mozilla, and you follow it.
Secondly, that it's wrong. In contrast to the above, the practice of
following Mozilla is wrong by any objective other than the economically
efficient thing to do, as a distro, as Debian, as an organisation. As a
community of open source, user-oriented volunteers, it's wrong.
Therein lies the rub. Why? This gets at the whole problem of PKI, and
this is what makes people tear their hair out for thinking too much
about it.
Assuming you wish to tear your hair out, read on. No shame in keeping
your hair and writing code instead, that's what I should be doing.
The easiest way to look at the problem is this: Mozilla also has the
same problem as Debian. Which is to say, Mozilla hasn't the resources
to analyse the CAs, so it follows audit.
Which leaves us at audit's door. And now we get to the core issue:
audit is a failed process. It is failed for many reasons but the key
one for PKI is this:
Audit follows a script that isn't germane to users' security.
The reason it is not germane to users' security is that it is written by
the insiders -- the CAs are the biggest providers of information as to
how they should be audited, they dominate on most or all levels, and
they pay big money for the privilege. So clearly, they provide
information that helps themselves and not necessarily anyone else. And
they argue against any changes against their interests. And, they're
good at their job. And, they pay for the right result.
Surely, you say, don't Mozilla and other vendors check all this to make
sure it is good for users? No, not really, not *effectively*.
Mozilla's policy primarily follows the concept of an audit [0]. They do
have in the policy the ability to drop a CA, if it is detrimental for
the users. They can put pressure on the CAs when clear problems arise
(e.g., the secret sub-CAs). They participate in closed-door sessions to
write new audit processes, so they can influence.
But in essence they have never made tangible what the user's interest
means, other than ... audit, and they've never deployed a critic of
audit on the job. For various reasons, most vendors do not have, never
had, and likely never will have deployed the capability to understand,
regulate and understand what audit really is about. Nor do they care,
it's not their business.
To be fair, PKI is hard to understand. I didn't understand it when we
were writing the Mozilla policy 9 years back, and I didn't understand it
for the first year or two of my efforts.
So how is it that I know, now? We know now because CAcert did something
that no other CA did -- it broke ranks and asked a non-PKI interested
party to do the Audit.
That person was David Ross. Who was a user. He realised that the
existing criteria were not germane, so he wrote his own, which we call
DRC. He wrote it from his viewpoint of what a user needed or could
sustainably argue was important for users, using long experience as a
systems engineer and quality reviewer. In DRC there is one key element
(stretched across multiple parts) which we call RLO:
The CA has published the Risks, Liabilities and Obligations of the
parties [1].
That one key element, RLO for Risks, Liabilities and Obligations, broke
CAcert. It forced a total re-design to cope. You can see the results
in the member's agreement, CCA, which was specifically written to state
and carry the RLO. And, to make members into 'parties' a key point that
became the crux of the infamous root licence [2].
RLO also breaks PKI as we know it. What does every other CA's RLO look
like? Buried. They cannot pass DRC. What does Mozilla's look like?
Not so buried, they now have, for many years, an End User Licence
Agreement that states their liabilities are zero, but the implication is
buried. Why are their liabilities disclaimed? Because, once you go
looking deep at the CAs, you discover that CAs disclaim all liabilities
and therefore if there is any snafu, the vendor is on the hook. Mozilla
must also disclaim because it chose the CAs, and it's the counterparty
with the user, not the CAs. Are you paying attention, Debian Legal Officer?
Which brings up the philosophical question of what certificates can be
relied upon for? The answer is nothing, if it means money.
Except at CAcert. In CAcert's statements, they say "file a dispute" and
they defer the process over to an Arbitrator. They don't say their
liabilities are infinite, but they do give you your day in court and an
Arbitrator has wide powers. If you're not a member, you still get your
day in court, and while liabilities to you are probably still zero [3],
and a judgement may not recompense you, this does not mean that the
certificate holder is held harmless.
Which may be why some people say they trust CAcert and no other CA.
At CAcert, *there is recourse*. This recourse is over everything, all
the time, every act; and it shows through in the professionalism and
care which people take. At CAcert, certificates mean something, and you
will find that meaning -- before an Arbitrator.
Whereas, other CAs have totally buried recourse. They disclaim
liability totally for everything, they hide it from you, and they market
certificates *as if* you can rely on them. Try it! If you ask about
the legal contract, the shutters go up. It might be an American
paranoia to never talk about liability, but in practice this is what
happens -- no CA will talk about its liabilities to you. It is
impossible to talk seriously about the benefit to the user without
talking about the liability when something goes wrong, and it is
therefore impossible to talk *seriously* to any CA or vendor about the
real meaning of the certificates or reliance in effect as opposed to the
wordage.
How can this be? Surely audit would have picked this up? It does and
it did. CAcert's audit process did pick it up and CAcert worked for
about 3 years to build the arrangement where it can protect itself (very
important) its members (as important) its vendors (also considered) and
also the users who weren't members (Principles say this is important too
[4]!).
Other CA audits did pick it up; but they didn't respond *in the user
interest*. They are focussed on protecting the CAs [5]! And, they are
very good at their job.
For the users, nothing. This is why it is wrong. The process is
basically rigged to ensure the business of CAs, in that nothing that can
ever go wrong can be legally bound back to the CAs. Now, happily
extended to the vendors [6]. But the users are screwed.
Users, go phish yourselves.
Perhaps there isn't so much excitement at CAcert to push forward on the
audit, after I withdrew, but I personally am comfortable with that
because it doesn't add to the user process that we hold paramount at
CAcert. The audit is basically antithetical to the spirit of an open
source, community project like Debian, like CAcert, and even like
Mozilla, maybe. Only David Ross's efforts ever did anything *for the
user* in the world of PKI, and his work is locked out.
Sour grapes, you might say, and I'm not going to challenge that. I
spent 3 years of my life to make it happen, and had to let it go.
Fighting against the juggernaut isn't a lot of fun, and as I suggest to
you, debian, just following Mozilla is the right, only choice you have
available.
Rather than getting involved in a broken, corrupt process, you should be
writing code. And so should I! Back to it.
iang,
sometime auditor of CAcert, now not really involved, and speaking for
myself only.
[0] Mozilla's policy:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
[1]
http://svn.cacert.org/CAcert/Audit/AuditCriteriaOnRisksLiabilitiesObligations.html
[2] The root licence is a very tricky document. Where we get into
legal trouble here is that users of certificates -- you out there in
debian land -- may or may not be parties to a contract. Other CAs will
tell you that you are a relying party, which means you have a contract
with them, that indemnifies them totally. If you dispute this, *you
haven't got a contract and therefore you cannot sue them*. This is a
deception. In CAcert, we do not deceive (it's in Principles!) and we do
not tell you that you are a relying party when you have no agreement
with us. We haven't seen you, you haven't seen us in your browser (!!),
how can there be a contract???
Hence, what there is, is an open offer licence along the lines of a
distro licence, and you are invited to arbitrate, but CAcert's
liabilities aren't going to be much. Because of the RLO issue, it
cannot and must not promise you are a party when you are not, and that
you can rely when the term is a deception. Very annoying, but the trick
is to ignore that FOSSL comparison and compare it instead to any other
CA. Are you getting uncomfortable yet? Those distros that criticise
CAcert on the basis of their "non-FOSSL-approved licence" can't even
find the contracts of the other CAs.
[3] If you want to learn why liabilities for CAs have to be set to zero,
then try section 4 in long thing:
http://iang.org/papers/open_audit_lisa.html
[4] Principles are here:
https://svn.cacert.org/CAcert/principles.html
[5] WebTrust used to have a clause in criteria that suggested that
relying parties should indemnify the CA (!?) so liability avoidance was
always part of the process. In later generations even that was dropped,
from memory. Embarrassing, or what?. You can see this with Thawte when
they dropped the WoT back in 2009 or so -- before that, the auditor
declined to audit it because the liabilities weren't properly handled --
which is to say, Thawte took on non-understood liabilities that weren't
properly zero'd out. CABForum can be seen as a cartel to ensure that
liabilities are properly controlled in the face of phishing (which is
what the vendors thought they were doing...). Once the vendors figured
out that they were potentially on the hook for unlimited damages, they
got the CABForum to put in an indemnification for them, CABForum's
Baseline Requirements section 18.2.
[6] I'm not being sarcastic about this, I agitated at Mozilla to get
their liabilities set to zero because they had been screwed by the CAs
as well. At least they are now aligned at zero, but once it wasn't so.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
