L I S A 08 "An Open Audit of an Open Certification Authority"
De-horning the Dilemmas of Open Trust Abstract
How does a lightweight community Certification Authority ("CA") engage in the heavyweight world of PKI and secure browsing?
With the introduction of PKI -- Public Key Infrastructure -- as a framework that brought together cryptography, contract law, and institutional views from postal and telecommunications ministries, the Internet security framework rapidly became too complex for individuals and small groups to deal with, and the Audit stepped into the gulf to provide a kinder face, in the form of a simple opinion or judgement call. Classically, the audit process oversights a CA for its suitability for reliance in the root lists of popular software distributions.
An Open Audit
- Secure browsing and PKI
- Domain of the professional Audit
- CAcert + Mozilla = open audit
- Did it work? Why? Why not?
Yet, a community of Internet enthusiasts does not match the classical target customer of an audit: little money, loose structures, no deadlines, self-directed tasking, uncertain customer list, all inspired by an original goal of as many free certificates as you can use. Internet communities can make up for an apparent lack of professionalism with enthusiasm, numbers, loyalty and innovative thinking, but does that help or hinder a formal, criteria-directed audit process?
This talk tracks the systems audit of CAcert, an open-membership CA, as a case study in auditing versus the open Internet, community versus professionalism, quality versus enthusiasm. It will walk through the background of "what, why, wherefore an audit," look at how CAcert found itself at this point, and then walk through some big ticket items: risks/liabilities/obligations; assurance and what's in a name; disputes and reliance; privacy and data protection; the mission of a CA; open governance; and systems and security.
Can CAcert deliver on its goal of free certs? The audit is into its 3rd year as of this writing; and remains incomplete. Some parts are going well, and other parts are not; by the end of the year 2008, we should be able to check all of the important areas, or rethink the process completely. Hence, finally, the talk will close with progress and status, and recommendations for the future.
Presenter
Ian Grigg
- Independent Auditor
- crypto, security, protocols, architect
- Payments, Trading, Governance
- Critic
- Comp Sci + MBA
- iang at iang dot org
Ian Grigg is Independent Auditor for CAcert. He has spent the last decade designing and building systems of financial cryptography, including payments systems and digital rights and trading systems, with a strong emphasis on secure, open and self-governing systems. Before 1995, he spent a decade as a systems programmer in a wide variety of businesses and roles. He is a frequent commentator on security and financial cryptography issues on the http://financialcryptography.com/ blog. He has an MBA from London Business School and a BSc(Hons, Computer Science) from UNSW (Australia).
|
|
This is a deep and open examination of an audit of an open Certification Authority, CAcert. [1]. It seeks a broad, more open and fuller style as a business briefing, rather than a detailed coverage of technical issues.
|
All readers should expect to come in for criticism, participants should put their hard hats on. The coverage is open, "warts and all," because the need is to improve, not pat anyone on the back. Many observers of CAcert have come and gone, knowing all is not well, and I think it is futile and insulting to hide the rather spotty past. Better, I propose, to present to the world a message of
|
"under new management."Getting better, each day.
In the beginning, there was nothing: no net, no browser, no root, and no list of roots. Then, one was added. One net, One browser, One root,
|
And then, another root, and another.
A list of roots! Which created a need for management. Who's roots go on the list? What's the process? What are the requirements?
For a while, root lists were managed by a more or less informal process that emerged from the market forces. The process involved negotiating with the software vendors (always), paying a fee (sometimes), and being nice (probably).
"Sometimes when you fill a vacuum, it still sucks."
Rob Pike, referring to something or other
It was into this vacuum that the accounting profession stepped, and created the leading expectation that the one, true, major requirement for being added to the root list was:
the systems audit.
|
The CA Systems Audit was created by the auditing profession, suggesting that CAs be audited on the same basis as other major IT security systems, a business in which the accounting profession already had a large stake. For example, WebTrust was created by the auditors in the USA and Canada, while ETSI was created by ????
Although an audit from an accounting firm can add value, it can also cause undue costs, and it can provide mixed or confusing signals. Does an audit signal that a CA is good enough? Good enough for what? And how do we know this?
|
The audit process seems to have generated more than its fair share of criticism. Salient criticisms include:
|
These criticisms may apply more or less to any of the variants, here they are listed without favour.
The informality of the root-list management process was the norm until competition in browsers started up again, around 2003. It worked well enough in the days of no competition, being roughly that period after Internet Explorer destroyed Netscape (the company and the browser) as a viable competitor, up until the arisal, phoenix-like, of Firefox. Where there is no competitive pressure, then the market leader does what it likes, and others follow or not, as they like. No clear guidelines, no strong rationale for one standard over another, and no commonality is required when there is a dominant player.
As Firefox started to show signs of success, questions arose as to how to "get into Firefox." Especially, loud and irritable competitors to established CAs asked these questions, as the path to their success lay through the root lists. Firefox then was the first port of call in those negotiations, because as the new challenger, it was small, light, nimble and thus the trend setter. Further, as an open product, an open approach to the root list was something that people thought was appropriate.
|
To Mozilla's eternal credit, these questions were seriously taken. Mozilla appointed Frank Hecker (later CEO of Mozilla Foundation until end 2007) to head a 2 year project to create a policy for ascension to the root list. This process was openly conducted on the public mailing list know as "mozilla-security" and archives will track the full debate. It took 2 years, thousands of emails, and the attention of many people.
The topic was briskly fought. Especially, the question of openness in audits was debated. Many felt that the audit should be conducted to the highest standards, and that was felt to be the WebTrust process established many years ago.
Others challenged this process on many grounds. However, in the event, the debate was resolved by allegations made by the very defenders of the audit process that certain of the WebTrust-audited CAs were conducting activities that no auditor should have approved (they said) and were directly against the interests of Mozilla users, and therefore against the interests of Mozilla.
What these interesting activities were, was never resolved, but rapidly, the group moved to promote a policy of openness, even to the extent of accepting an open and independent audit process. (It should be said, to be fair, that the notion of not relying on an audit at all was not seriously explored.)
This extraordinary departure opened the door to allowing open CAs such as CAcert to conduct open audits, but the issue was not solved, only simplified; the audit still needed to be conducted to external and independent criteria.
|
Enter David Ross, a frequent contributer to the above mentioned debate. As a critic of CAcert, and as a long-term quality engineer, he was encouraged to start an audit of CAcert on the basis of the emerging policy. Ross did not get as far as starting the audit, but he did write out a new criteria that updated the old, venerable WebTrust version. Ross found other commitments in the way of attendance on the Grand Jury of his domicile.
At this point, Ian Grigg then stepped forward and agreed to audit CAcert on the basis of the criteria written by David Ross (henceforth, "DRC"). He, or I, was a long-standing critic of the entire process, so is apparently well versed in at least the weaknesses.
The initiation of the audit and consequent mission was driven primarily by Mozilla's requirement for an audit to get into the latter's root list for its products (Firefox and Thunderbird).
The process of the audit then was driven by (a) the Mozilla policy, which resulted in (b) the criteria known as DRC (discussed below). The choices found therein were informed by several circumstances,
The audit may or may not be applicable or exandable for other purposes. What was still not clear from the origins was what the overall goal of the audit was. After much thought and much experience, the following mission was suggested.
To review and report on the suitability of CAcert's CA
to enter the root list of Mozilla Foundation.
However this is somewhat unedifying. In practice the higher goal has been something like:
To review and report on the suitability of CAcert's CA
to present certificates to,
and provide some utility and protection to,
end-users of browsers such as Mozilla's.
|
That is, unlike other processes, CAcert has specifically moved away from following the flavour of the audit process, and incorporated the end-user as the real customer. This has some ramifications, some trivial and some quite severe, which we shall see soon enough.
The criteria, ("DRC") are divided into 3 groups or phases, being A (documentation), B (public access), and C (operational review). Within those broad areas there are subsets. Like all tree-structured representations, there are substantial horizontal threads, although these are less well defined.
A full description is best done through reading the source. Here is a summary of the main areas:
|
How then does DRC compare to other criteria? In essence, there are these differences to WebTrust:
|
For CAcert, the criteria introduced several big issues, which were in retropsect solved easily.
In common with most quality processes the DRC identifies a set of important and therefore controlled documents. DRC-A establishes the Configuration-Control Specification ("CCS") as the set of documents and control policies for those documents that are considered to be so important to the CA's integrity and good functioning, that they form a part of the audit. In other words, the "controlled" set.
From the point of view of the process, this part is simple: identify the document titles, find them, or write them, have them approved (first by the organisation, second by the audit), and make sure they are being used. Simple to say, and it hides a lot of work, but at least this part should have presented no challenge to the average organisation.
However, CAcert was no average organisation. When CAcert started, it had little of this in place. As of early 2006, the process was that the Board would approve documents, and a policy maillist existed as a place to discuss them. However, few "controlled" sets were identified. no timeframes were established, and indeed no forward plan existed at all.
An interesting sidebar occurred here. One document that existed was the CPS, or the Certification Practice Statement. This is the core document for a CA, the one that more or less describes everything that should be described. So the presence of the CPS was a good start.
It was however owned copyright by another organisation, and was being used under licence. This sat oddly with the overall sense of "control" as pushed by the CCS. It turned out that the author had (quite valid) concerns about the open source pedigree of CAcert, and had deliberately arranged matters to place the ownership with the Free Software Foundation, and licence the document under their Free Document Licence.
I pondered this and worried about whether the FSF could indeed exert pressure over the CA using this. Although it was unlikely that the FSF would do this for bad reasons, they might very well try to do it for what they perceived as good reasons. To resolve this, several choices were offered:
In short, in negotiations, the FSF confirmed that they could and might indeed try to control the document in some sense. They however suggested that we trust them, as they had our best interests at heart. And, no, they were not going to hand the copyright back.
In the end, CAcert elected to rewrite the CPS entirely, from scratch, and this time keep ownership. As the document was well short of audit requirements, anyway, this was the better choice. To be fair, I never looked at the FDL, but I was told it was more complex and less understandable than the famous GPL. Such seems to be a cruel and unusual punishment, and at least beyond what you could ask someone to do in their own free time.
It proved fairly easy for the CA to knock out a list to match the requirements imposed by DRC-A. The Privacy Policy was modified with 3 additional clauses, driven by DRC-A, and this was approved by the Board. Slowly, additional documents in the controlled set were created and brought to some state of usability.
However, the process then hit another issue: the policy for approval itself. The Board simply declined to approve anything more complicated than the three clauses added to the Privacy Policy. Documents backed up until crisis struck.
In response to the backlog of policy approvals, it was proposed that this very approval of policy should then migrate to a more consensual style in the spirit of the IETF. In brief, let the entire cycle of policies be done by the community, on the open policy mailing list. From proposal, editing, agreement on draft, and right through to approval of the final document, this could be done on the open subscription mailing list.
To that end, such a policy was drafted as Policy On Policy. This approach reduced the Board problem from Order(n) to Order(1), at least, on paper, assuming it could be approved. The above-mentioned set of backlogged documents could then be handled more quickly, as could the backlog of other policies outside the controlled set.
The process also creates a gap in governance: what do we do with a rogue policy committee. To deal with this, the policy permits two significant escape valves. Firstly, the Board retained a veto over policies that were in the intermediate stage of DRAFT, but the right expired when the policies enter their final concrete status. Secondly, any user can take the policy to the forum of dispute resolution and seek a ruling. The move to Arbitration as a means for internal dispute resolution, described later, provides this oversight formerly handled by the Board, albeit in a novel and untested way.
According to its own process, it could be deemed approved. Yet, to deal with the bootstrapping problem or replacing the old approval process, it itself needs to be initially approved by the Board in order for the CA to proceed on its audit path. It is fair to say that the sum of these changes are significant, and in the event, the Board declined to read it, let alone accept it. This became one sign of internal trauma, of which more later.
DRC: R / L / O
|
The major area where DRC departs from WebTrust is in the issues of Risks and Liabilities. Consider these Criteria, briefly here, and compare the DRC approach to the WebTrust approach.
Include ../CAcert/Audit/AuditCriteriaOnRisksLiabilitiesObligations.html failed - No such file or directory
Both require the listing of Obligations and Liabilities of Subscribers (for DRC, A.3.e, A.4.d, A.6.c, A.6.d, B.2.e, B.2.5. For WebTrust, 4, 14).
There are subtle differences: DRC requires the CA to state the Risks (being bad things that might happen) of all parties (A.1.h, A.3.j, B.2.c), and especially for the end-user (A.6.a). Further, the CA has to state the Liabilities that it itself is prepared to take on (A.6.b).
DRC requires that the risks and liabilities of all who come into contact be stated, more or less. The weight of criteria on these points stress the emphasis in a way that it is hard for a CA to avoid; end-users and the public have a right to see it clearly and fairly, and the CA is forced to be open and thoughtful.
WebTrust on the other hand permits the CA to define this quite loosely with its criteria 4,5:
|
With WebTrust, the Relying Party is expected to carry the load, whereas DRC spreads the load across the three or four parties, and insists that all the components be documented. In comparison to DRC, WebTrust's rather brutal "indemnification by relying parties" seems to predict it is slanted towards ensuring that the CA is protected from the users. This may be a useful commercial objective, but it seems decidedly odd for a systems audit, and its utility to a vendor or end-user has to be suspect.
|
What is left unstated, and is therefore unclear in WebTrust, is just how these criteria could be interpreted in an audit? Do the said apportionments, above, have to be notified? Is it acceptable to bury the indemnifications in fine print, or do they have to be advised and accepted by the users? As this is not stated anywhere, the clear incentive is to not do any of it.
To underscore this, we can examine the language used, and we find a significant difference. Following PKI convention, WebTrust talks about the relying party whereas DRC talks about the end-user and the general public. Approximately, these terms refer to people who are not subscribers, rather, those that are given a certificate in order to start an encrypted protocol, check an identity, or check a signature, etc.
|
This difference in terms is not just a minor issue, it is a major shift in liability, as we will see. Relying party is a term that has to be defined, and effectively, we can define a relying party to be any person we like. Indeed, this is just to state PKI convention, and the place to define the relying party is the CPS.
Whereas end-user is a term for which we already have a widespread and broad definition in the language. The end-user is the user of general purpose software, such as a browser user, without any special caveats. A limiting definition to end-user would stick out baldly and badly. Further, although the term end-user might be validly discussed in court, there is no chance of re-defining who the general public is, nor of arguing it.
|
In DRC, the audit will hold the CA to stating the situation for all end-users, a situation that is obviously aligned with the interests of those users, and the browser vendor. In WebTrust, there is all encouragement to ignore the end-user totally, and to limit the liability to those who do chose to become relying parties.
What then goes on in practice? The favourable path is as expected: CAs generally define the relying party to be those who have directly entered into a user agreement with the CA. That agreement then expressely seeks to limit the liability of the CA to zero, and to dump it all on the new relying party [3] [4].
|
Outrageous, you might say, and this would be the popular criticism! Except, there is one slight issue with this easy cry, and it is a killer issue drawn from simple logic:
If the liability of the CA to the end-user, or worse, to the general public, is not contained, then the liability may be incurred by the CA. Multiplied over all end-users, it is simply unbounded. Consider, for example, class-action suits for phishing.
|
It is then essential to contain this liability in some way. That is, we must have a number, and we must have some risk figure so we can multiply these numbers out and cover the costs.
Indeed, it turns out that
Zero liability to the general public is the only sane choice.
|
By way of counter-example, let's say you want to set the liability to $1 for each user. According to some measures, this could mean all who saw that certificate, all users of Paypal, or, all users of the Internet. In a class action suit, this could mean a buck for *everyone* As there are a billion of them out there, and they keep on growing, this is not what we would call "bounded" in any rational sense.
You want to offer less than a buck? The only sensible number for liability is zero. The way forward is, no matter how outrageous, to disclaim all liability to the general public and to use whatever legal and technical defences are at hand to set the expected liability to zero.
|
Which then leaves us with a dilemma. What good is the CA? Who does it serve? If a certificate gives no protection if it goes wrong, what's the point? If Bob gets phished, how much does the certificate pay out? Zero?
What exactly does a certificate do for the end-user?
And, serious students of business will ask why did Netscape foster the world with this rather odd, asymmetric and legally-fraught arrangement? Cynics will immediately spot the issue here and say that the CA serves itself, and only itself. (Gee, thanks Netscape!) Well, if CAs manage to disclaim all the liability, to all the people then the cynics might have a good point. Indeed, it may have been this very issue that prompted Mozilla to add in the following clause to the Mozilla CA policy:
|
1. We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products.
Matched in slightly more ego-centric form by Microsoft [MRCP]:
|
Please describe how the services for which your root will be used to provide broad value to Microsoft customers.
...
Roughly speaking, [broad value] means the benefits to including the root certificate outweigh any risks to Microsoft customers. Among potential benefits include alignment of a CA's certificate issuance with Microsoft strategies.
|
There are ways out of this dilemma for the CA.
|
|
Remembering that DRC forces the open disclosure of the full story, CAcert has to take the bull by the horns [5]. CAcert chose these basic tactics:
|
This seems to be a fair offer, although it is somewhat different from what has been imagined. Outsiders can use the certificates, just as is in common with other CAs.
|
The difference so far is two-fold: Firstly, CAcert will go to the extent possible to tell all users what the story is, and will also attempt to push the appropriate story to others, the non-related persons with whom by definition CAcert has no relationship. Tough challenge!
Secondly, instead of attempting to bind the relying parties to a liability of zero, by means of legal devices layered one after the other, CAcert seeks to explicitly set some value in place. As it happens, that value is serious:
|
This still leaves a problem. If an insider can claim some value as damages, we still have the same old problem of unbounded liability. Above, we said that any value multiplied by an unbounded user base was unacceptable. As CAcert has unbounded admittability in users, this is potentially the same issue.
|
In order to avoid the trap of unbounded liability, CAcert simply allocates the liability back to the users. And this "judo trick" is where the user agreement really starts to show its differences.
Users are not promised coverage of €1000 as implied above. In fact it is entirely the reverse: Users are told that they themselves are liable for that amount. Indeed, by entering into the user agreement, the users are worsening their apparent liability position from an assumed zero to an amount of €1000.
In order to accept this, users would presumably have to value the certificates. But what is far more important is how this liability is passed through from one user to another.
As with judo, such legal pass-throughs need rules. In order to transfer the liability in a bounded manner between the Members, CAcert establishes its own jurisdiction in law, and binds all users into that jurisdiction.
The technical, legal way of doing this is by by means of Arbitration, which is sometimes referred to as a form of Alternate Dispute Resolution or ADR. CAcert's forum is discussed in a later section.
|
In summary, CAcert creates two groups of people, being the Members, and the Non-Related Persons. Where the paths separate for the two classes of people is in the user agreement that either class is faced with. If you as a user have agreed to the CAcert Community Agreement ("CCA"), you are on the "inside", you are a Member, and you can take your grievances to the forum of Arbitration. If you have not agreed, you are on the outside, and any liability is disclaimed.
|
Those users who have agreed to the CCA are referred to as Members, and are permitted to RELY on the certificates, which means they can make a financial or otherwise risky decision that requires and is effected by the information in the certificates. If it goes wrong, if for some reason their reliance does not work out, they can sue for damages in Arbitration. In counterpoint, these selfsame insiders are made liable for their own actions, and liability to them is accepted by the CA itself.
|
The second group are offered a licence to USE the certificates. Much like an open source licence, the users of browsers are permitted to use the certificates as they are presented by their software, or by a CAcert Member at the other end of the protocol. What they are not permitted to do is RELY, which means they cannot make a financial or otherwise risky decision that requires the information in the certificate. The disclaimer of liability is simply the flip side of there being no permission to RELY.
Where is CAcert Inc., the legal entity, in all this? The Board? The systems administrators?
|
According to Policy on Policy, all policies are binding on all Members and that includes the CA itself. The rules of Arbitration are such a duly approved policy, so CAcert Inc., may appear before the Arbitrator with the same standing as any other Member.
As all volunteers to CAcert are Members, including the Board, the Systems Administrators, and other roles, all parties are before the Arbitrator, equally. Indeed, within a day or so of the policy being approved, the Auditor as Member was called to Arbitration [6]:
- Case Number: a20070921.2
- Status: Complete
- Claimants: Jens Paul
- Respondents: Ian Grigg
- Complaint:
I, Jens Paul, Cacert user, hereby designated Claimant challenge the CAcert registered user Ian Grigg for stating that he is an Assurer during the Exec Event. As the CAcert system clearly states, Mr. Ian Grgg has less then 100 points and therefore he is not an Assurer and should not be allowed to act as such a person.
- Case Manager: Philipp Gühring
- Arbitrator: Greg Rose
- Date of arbitration: 2007/12/28
- Relief: Mr. Ian Grigg is not allowed to claim to be an assurer until he has 100 points and has passed the appropriate Assurer's test. No penalty is assessed at this time, but the respondent is warned not to repeat the offending behaviour.
There are no exceptions within CAcert to these rules, and as the concept of Arbitration is uniformly promulgated throughout the CA, this travels some substantial distance towards meeting the spirit of DRC: be fair to all.
What then means USE? According to the various policies, it is that which your software does for you, and that which you never do for yourself.
|
The general public come into contact with certificates in approximately these ways: email, and encrypted SSL webservers. USE works very well for encryption of email, because we simply want to turn on the crypto, and not ask who our counterparty is (us users already know who we are talking to, even if the PKI Industry persists in telling us that we do not). USE also works well for encryption of web server traffic.
However there is one exception: USE falls somewhat short when ecommerce may be involved with non-related persons. This is because ecommerce may involve a RELIANCE by that non-related person, e.g., the act of putting a credit card into an encrypted website. Partly for this reason, CAcert does not recommend ecommerce in its CPS, preferring to indicate to Subscribers that, as NRPs are not allowed to rely, exposing credit cards may complicate the position for the Subscriber.
This offer to USE is delivered in licence agreement best thought of as the agreement that comes with your open source: you probably do not notice it, but nothing else gives you permission to USE. In that offer, there is also a ban on you RELYING on the certificates, and some other administrative limits.
And now we see the final expression of PKI: the Members who have agreed to the CCA are the relying parties. In contract form, CAcert is little different from any other CA, however what that contract agreement states is very different.
|
RELIANCE is then defined to be any decision that you the Member (!) makes on your own. Explicitly, it is not that which your software does for you.
Actual Value in Liability. Members are explicitly given a liability limit of €1000. They can present their case, and conceivably get an award of damages, although it is entirely up to the Arbitrator to rule on how much to compensate each party, and from where this value is derived. It also means that claimants and respondents themselves are the community, and the balance of fairness for them and everyone else must be sought. What is unusual is that for the first time in CA history, a large group of users have a clear ability to go and get satisfaction.
This great edifice is constructed of three key policies which are, if laid end-to-end, would probably be shorter than the above entire description.
|
|
You may be asked to help NRPs in security. It is your choice to do so, but if you do, you should not act to their detriment. You should encourage NRPs to join the community. While we work for the benefit of our own users, we must balance our benefit against harm to others. Achieving a benefit to ourselves at the expense of others has no part in our principles. Other users may join, and they become of us. We exist to help the security of our community, but we also exist to help the security of everyone. http://svn.cacert.org/CAcert/principles.html |
Finally, a sister document called the Principles of the CAcert Community documents various practices. These are those things CACert Members might desire, but find difficult to turn into a hard rule. For example, the Principles includes a clause that says "We do not act to the detriment of NRPs."
Rather than defining such a thing, it is up to an Arbitrator to look at whether this principle is breached.
For perhaps the first time in certificate history, CAcert is now offering all its own users a good deal. They can USE and RELY, and if something goes wrong, they have recourse. Further, that has been done without harming the interests of the wider public, unduly. In exchange for the confusion of the past, the general public has clear permission to USE. And, although they cannot RELY, they are permitted to file cases, and can always join as a Member, for free.
|
Much remains to be done. But what has been done has acheived something that is implausible under WebTrust: a good deal for the users. Further, the strength of the basic mechanism means that as a group, security can be the aim, and cash flow can be subordinated to that aim.
In around 2004, the business of CAcert was transferred fully into an Association of Members, registered in NSW, Australia. Included were minuted agreements to transfer the domain names, servers and source code from the founder, Duane Groth, to the Association. A board was duly elected.
These steps created the foundation for CAcert as an independent and professional business. However, a foundation only: the house was yet to be built.
|
Above, we touched on the topic of submitting policies to the Board for approval. As well as the lack of progress in policies, there were other issues: lack of feedback on any questions, lack of any minutes or published decisions, apparently years behind on financial reports and AGMs, lack of response to requests for costs.
A critical test was reached around mid-2006 when I insisted that the Board approve the disclaiming of all liability to the general public, "or else."
Unfortunately, in the panic to avoid unstated sanctions, the Board voted on a garbled proposal forced on them by non-Board members. The result, or whatever could be determined from the email conversations, could be read any way we liked. Literally, it appeared to accept the feared termination of the Audit, rather than their apparent intention to agree with the demands.
In effect, the Board had proven they would simply decline to approve anything, unless nailed over a barrel with roughly-cut splinters, and slowly lowered over shark-infested waters with burning tapers between their toes. Even then, the members would conveniently fail to recall what it was they were asked of, and would yell out agreement in piratical harmony to anything at all: "We agree! Have mercy!"
This left CAcert in the position of grave uncertainty: I had secured some sort of agreement but was unable to work out what the agreement was. I checked with four different Board members and none were able to describe what it was they had agreed to. In detail, I was left with no choice but to proceed with my own directive on the issue at hand. In the wider picture, there was now sufficient evidence that the Board was dysfunctional, and something had to be done.
|
It was clear by mid-2006 that CAcert has led by a team that had failed to grow with the organisation. The big question was, what to do about it, and what part does this play in the Audit?
There is no criteria that says
"management must be competent to consider, agree and approve policies wisely,"Likewise, the USA auditing profession's Attest Standard suggests, not to take on an engagement that cannot be completed, but says little on what happens if one is already engaged. Not so helpful!
However, in the Audit Opinion, being the ultimate work product of the audit, there is phraseology that starts:
Management has put in place policies and procedures....
This gave me the way out of the dilemma. If the management cannot meet this standard, then the Audit cannot conclude. As there was a provable lack of new policies and procedures, it could be asserted that there was no Management. The process of raising the pressure to change the situation then became one of repeating this claim on the mail lists and in other forums of importance. No management, no audit. Logical, reasonable, and while novel, it was sufficient to raise the red flag.
What was less clear to those who cared was what to do about the dramatic claims I made.
|
And, publically, there were no suggestions offerred. An Auditor is not engaged to review the Board, but the CA. Only within the context of the CA and its audit can any strong opinion be made. More particularly, although it might be possible to suggest the Board is not up to the job of managing the CA, it is a very different thing to suggest what it is that the Board should do about the situation.
Hence, the opinion was couched in terms of "no management," which might have been interpreted as a request to the Board to appoint a manager. Of course, the Board did no such thing as the real and underlying issue was not the absence of managers but the absence of the Board. In time, the absence of all meaningful management activity reached even the slowest and darkest corners of the collective consciousness, and, one by one, the directors resigned.
With the apparent reduction of active directors below 3, around March 2007, the Board entered a state wherein it could no longer form a legal quorum, and therefore could make no decision. The Board was completely frozen, and the onus now shifted to the Association to unfreeze their Board. The members rallied together, called for a Special General Meeting, and voted in a new Board on 25th May 2007.
Success is a lousy teacher. It seduces smart people into thinking they can't lose.
Bill Gates
The root of the issues with CAcert during the years 2004 to 2006 is what is known as the Founder Paradox. In brief, one person has a bright idea, makes it happen, and becomes the master of all he surveys. In time, the business grows to the extent that it outgrows the ability of that original founder to see all the aspects. At this point, a team is required; but it does not get put in place because the original founder believes, more or less, that because he got it to where it is now, he knows more than any team.
|
Students of business know this from their b-school cases on family firms. What is not known is how to deal with it, as there is no good strategy, no 5-points HBR summary to solve the founder problem. It takes years, it's always painful, and many companies fail. Above, in CAcert's case, the answer derived from the earlier 2004 decision to place the intellectual property and the community in the hands of a formal Association, and to elect a proper Board. As this Board failed in due course, and confidence wavered, the Association was still there and was able to rally together to save the day [7].
What is also left as the founder's legacy is that once he or she moves aside (as he or she or the business must, in the end), there is a vacuum. This is the founder's legacy. CAcert was no exception to that, and suffered from a predictable and widespread trauma in building up a team and structure to make the organisation work in the aftermath of the loss of its one most productive member.
Luckily, CAcert was an open and popular organisation, and things happened to guide it.
As 2006 drew to a close, and as the directors were resigning, matters came to a head in many areas. Action was called for, care was needed. Unfortunately, several issues came up which indicated that the organisation was in more trouble than expected.
Firstly, the servers. As CAcert operated nominally for free, it had no budget to speak of for server costs. Which meant that the servers were colocated at a "friendly business." Now, it needs no great experience to predict what happens in that case, and the business turned unfriendly in due course.
|
The movement of the servers out of their current location then became critical. Joyfully, a very attractive deal was offered by NLnet, a long-term funder of good works, to finance and manage a rack's worth of equipment in a secure center.
This deal was wonderful, economically, yet complex, legally, and governance-wise. Setting it up took time and attention, and what was perhaps more important, skill. Pressure mounted to secure a deal, and it became fraught. The pressure of time clashed with the needs to secure the operations and maintain a long-term strategy beneficial to the users, and CAcert found itself being pushed into a deal that wasn't good for it.
Secondly, as Mozilla was still "the prize" in many people's minds, and the audit was apparently taking time, alternatives were looked at. The basic concept was to subordinate the CA's root to the roots of other CAs already "in". Via subroots, CAcert certificates would then be represented within the browsers, but for all sorts of business reasons not covered here, the users would also eventually transfer to the new CAs. In short, this is no different to any other insider sellout, except with the possible absence of the customary under-the-table payoff.
The first of these efforts to merge with another CA was a fairly obvious ploy that was spotted by the Founder. The second however was not, and discussions had advanced to what appeared to be a verbal agreement around a draft Memorandum of Understanding.
No experienced manager was in place who could deal with contracts and commitments. When too many of these exceptional cases occurred, I decided in December 2006 to assert direct oversight.
|
This act was not done lightly. If this were a financial audit, this would be a signal akin to bankrupcy or other failure, and within Australian rules, I would be required to report this event to the financial regulators. The severity of oversight needs to be seen in that context.
Not only was there an impact on the CA, but also the allocation of liability became difficult to control. Potentially, anyone could then blame the auditor for any misfortune that followed. No matter the rightness or fairness of any such claim, there would be distractions, challenges to independence, and even suits and costs.
On the other hand, there were in the order of 100,000 users to consider, and the wellbeing of the directors and other people on the inside. The actions were creating potential liabilities for the directors who remained at the time, and they were clearly not capable of understanding or handling these responsibilities.
|
After some thought, I decided to take the following steps:
This was done by signalling in maillists the above points, as and when I felt necessary. This effectively placed the CA under administration until the creation and bedding-in of the new Board. This situation was kept up even after the new Board, as there was no guarantee at that time that the new Board would be able to pick up the pieces.
The old "core team had already taken some steps to put in place more structure. This initiative had two components in a matrix form: a horizontal "products" arrangement, and a vertical "department" arrangement. Over the period of 2006, some people had been slotted into this with only limited success, for the usual reasons: Granting a title to someone does not a manager make.
|
The second attempt was far more successful. As we crossed into 2007, two other interested people started to put increasing amounts of time into the project (I have chosen not to name names in this document, but for sake of clarification, these are TH and JP). One was able to secure funding for the creation of the new data center, and the other agreed to take on the education responsibilities that had been created due to the audit.
What became apparent over the months of the crisis was that these two very experienced people, along with myself, had the experience to make this happen. However, we all had a very big issue: none of us could take on any formal decision-making role or take on any responsibility in the management of CAcert. All for different reasons, it seems, but the result was the same: no responsibility nor any decision could be made.
"Nature abhors a vacuum."
Some physicist.
|
To solve this dilemma, we took a leaf out of the European book of corporate governance, and created an Advisory that had no powers, no say, no responsibilities and no tasks. In essence, we just gave ourselves a title. And started saying things.
In a vacuum, grey hairs generate less friction, less entropy and less lateral temptation. In effect, although we made no decisions, our words, our careful questions, and our complete examples of policies rode above the storm of white-noise normally experienced by such organisations collapsing into chaos.
Along the line of "this is what you could do," CAcert then proceeded to sort itself out:
|
It is fair to say that in the vacuum of the frozen Board, Advisory rode these issues fairly hard. Advisory continued to pick up a lot of areas while the Board was finding its feet. As the Board ramped up in its capabilities, the Advisory gradually faded into the background. By the time of the full AGM of November 2007, Advisory was no longer active in its previous form, and was replaced by a formal management sub-committee designated by the Board.
|
The election of a new Board then presented an opportunity to unwind the drastic step of control by Audit. However it was not without doubt; what would happen if this Board failed? Would they even understand the issues of handover? Should all things be unwound or should only some things be re-started? What of the liability for proper decisions?
In the end, I delayed. The Board moved slowly, and did not in the first few months look at anything big or critical outside their limited domain of meetings and procedures.
However, the decision to meet in September, 5 months after the SGM, put the finger on this issue. Hence, this document was first started as a briefing paper for presentation to the Board at the September meeting, and included a delicately placed question as to whether the Board was ready to ask the Auditor to stand down.
The predictable resulted: barely suppressed outrage, much muttering, and "damn your eyes, sir!" Which easily cleared the way for an informal suggestion for a formal decision from the Board to assert that it was "up to speed." And, the Auditor was to revert to more conventional duties. This established a firm date as to when any liability, etc., be capped, and terminated the affair. An unfortunate and difficult period for all involved with CAcert was now over.
|
In a 3 day session, the new Board read through several policies, line by line, and approved them all.
With this massive injection we were back on track, and the documentation requirements for audit were now around 50% complete.
The executive meeting was one of the highlights of the CAcert experience. In a few days, a room full of professional managers cleared through pretty much the entire backlog. I consider this to be to be a testament to these factors:
|
Many of the issues that CAcert stumbled over, during the audit and other forces, were traceable back to that old saw: the lack of a good mission. For students of business, this section will be familiar, and might be skipped.
To be fair, CAcert was not so far off in this department. Two "primary goals" are boasted on the website.
|
Goals here are things that we are doing that are important to us, they are significant, and they have a beginning and an end. Both above goals qualify.
The problem then is one of completion. What happens when the browsers include CAcert? Do we sit back and congratulate ourselves on a good job? What happens after apocalypse, and the software vendors start distributing opportunistic keys, wherein no CA need apply?
What happens is what the mission says; this is the one thing that defines us, the one thing that we do, and always do. With it, we are who we are, and successful, without it we are failure, we have no other names.
So when the CA job is done, we go back to the mission, and ask "what next?" When a topic comes along that doesn't exactly speak of the CA role, we go to the mission and ask it for its wisdom.
Of the above, the first two are really goals, and the first drives the second. The third makes CAcert too responsible, and falters on the fairly vague definition of security.
The last is my favourite. Let's take it for a test drive.
| Question? | Answer == Mission |
|---|---|
| Why is CAcert running a CA? | Because ... |
| Should CAcert hook in as a subroot under another CA? | If ... |
| Should CAcert advertise other CAs on the website? | When ... |
| Should the servers move to Europe? | Iff ... |
|
If it sounds good for all the difficult questions we can find, then we may have a winner. If not, more thought needed; and try substituting another mission.
The mission helps to define things that should be done, and as importantly not done.
As the mission is neutral, it helps to resolve opposing camps, and to keep people honest. If they can show their proposals lead logically to the mission, without challenge or undue cost, then the proposals are strong, and the people proposing are less important.
It also sets the future. As CAcert moves into a mature CA rollout, it can take pause and think what the mission suggests should be done next.
|
The basic idea of certificates is that it shows your identity to people. The theory is that if your identity is good, you can do some trade or communication with others who also have good identity. The certificate will communicate that good identity, and will also let you use some crypto to further secure your trade or communication. This could either be encryption of your traffic, or making some claim about another document ("I'm selling my house!") or yourself ("Hi Mom, it's me!").
Then, as a basic expectation, all Certification Authorities should:
|
Clearly, this (very) basic idea depends heavily on something called Identity.
|
In order to manage your Identity, CAcert adopted the web-of-trust model ("WoT"), as pioneered by the PGP community. In a web-of-trust, each of us can state what we know of a person, and sign that information so others can reliably get at it. The underlying notion is that we the people have a better grasp of who we are, and a capture of the distributed links of relationship will tell us what is useful to know better than a centralised service can deliver the information.
As an old PGP hacker myself, I have little trouble with the concept, but the details matter [8]. Specifically, the PGP web-of-trust was fine as long as nobody relied upon it. And, even then, as long as each individual understood that the information was raw opinion from others like themselves, and the reliance was on an as is basis, it worked. Of course, these claims apply to most every design, including the competing notions of PKI.
|
CAcert adopted its WoT further by limiting the statements of people's Identity to people they call Assurers. This was possibly adopted from Thawte's "notary" model. Each Assurer can give up to 35 points, and as you need 50 points to get a Named certificate, this implies checks by two independent people. The Assurers were defined as people with 100 points, thus implying that they were vetted by at least 3 other Assurers.
|
CAcert's Assurance network consisted of around 10,000 people, checking over a base of some 100,000 people. At its simplest level, the Assurance process is a careful human face-to-face verification of government-issued photo-Identity documents.
|
In contrast to the above notions, the PKI idea was grounded firmly in an authority for every important act. This is mostly traceable back to the golden age of telecommunications whereby national champions had a licence from a government, generally one only per country, to control the communications of a country. In that world, it was an article of faith that the answer to any question could be found in the designation, or creation, of an authority. Preferably a single, national one, but always one with gravity.
|
In the PKI literature, a single Registration Authority is generally required to verify the user's Identity and vouch that to the CA. From a helicopter view, we can see that the differences are much smaller than talked about. From the anarchy of web-of-trust, CAcert reduced the statements to a few thousand Assurers, requiring two of these to agree. From the superficial authoritarianism of the Registration Authority model, recent commercial models pushed the function out to thousands of external companies, and recent audit designs now require the process to be conducted by two or more individuals within an organisation. In this way, the differences between CAcert's system and the PKI model are really at the detailed levels of quality, and not at any fundamental level of design and structure.
|
In the event, DG put in place a relatively good system, so only minor tweaking was needed. We can attack this concept at three levels, being what, how and why.
First the standard. It seems to be clear that the standard of your Identity is critically dependent on the documents that attest to your Identity. In this context, CAcert had more or less decided to go for government-issued, photo identity docuemnts by the time this audit had started. While this standard has many, deep, political, philosophical and geographical issues, it doesn't really get any better. To cut short a long story, this standard was accepted without change.
Second, how is it checked? CAcert had already decided to check the identity of the users with the users themselves, as decided above. As described, at least two Assurers would check the identity before it could be put in your certificate, and three at least were required before you could also check others' identity.
Quis custodiet ipsos custodes?
Decimus Iunius Iuvenalis, a.k.a. Juvenal
|
Which led to a several problems.
CAcert had few answers to these questions, but with some prodding, several responses evolved.
|
add to current system:
|
Such things did not exist, although some things did fill their places. A wiki with a lot of ideas and procedures served as documentation, and testing was more done by the practical but informal check of experienced Assurers working with newer Assurers. However, these were unreliable. Firstly, there had not been a solid grounding on what Assurance should be, and the wiki varied in its treatment. Secondly, not only was any checking subject to obvious variation, it also tended to encourage the variations to bed in and become divergent standards, often on regional bases. Thirdly, there was a belief that the Assurers were better able to judge everything themselves, following on from the web-of-trust school of thought.
|
In order to escape from the maelstorm of variable quality, discussion inevitably spiralled into a need for a test. This would be a basic benchmark which could later be changed and tuned as experience develops. Once the concept of testing the Assurers was accepted, the thoughts of the techies immediately turned to creating an online test suite.
Luckily, an experienced leader of real business projects had turned up at the time, and agreed to take on the challenge. CATS or CAcert Automated Testing Sysem was created over the year 2007 with volunteer programmers, and opened up for general testing of Assurers, beginning 2008. By November 2008, 1200 Assurers had attempted and passed what had now been christened as:
The test is a series of around 40 questions. The pass mark is 80%, and a candidate can take it as many times as liked. In essence, as well as a benchmark, the test has a learning effect.
|
Unusually, CATS was built and run outside the main CAcert environment, so there is a communication required between CATS and CAcert. After much discussion around privacy and security, client certificates are required to run the test, and the result is communicated by client certificate number; CATS itself does not need to know who you are, simply that you are a Member, and your membership can be uniquely identified to CAcert with the positive result. This was a unique and valuable chance for the whole organisation -- Assurers and managers -- to learn about client certificates.
Unchallenged Assurers will lose their status, and while the code is written to enforce that, it remains for the switch to be thrown. This means in effect that the body of Assurers will shrink from some 10,000 to something under 2000. As CAcert has been collecting these names for some 6 years now, it is reasonable to expect a dramatic shrinkage, as well as professionally responsible to keep the status of the data up to date.
As mentioned above, there was no solid grounding in what an Assurance was. Indeed, there had even been a rule that "Assurers can do anything", and occasionally this rule was taken to heart by overzealous Assurers who were sure of their own realities.
|
Unwinding that rule took a long time. The first nail in the coffin was liability, as most of the Assurers equated freedom of action with zero liability. However, courts would be unlikely to agree to that. Luckily, the crafting of the risks, liabilities and obligations project resulted in the creation of the CAcert Community Agreement which both formalised the liability of each Member, collected it before CAcert's own forum of Arbitration, and put a limit on it.
Then, the project to build and impose the Assurer Challenge woke Assurers up, to the extent that they knew it.
The final requirement then was an objective policy against which the test could be written. This was the first major work of the newly empowered policy group. As its major act of 2007, the Board had passed the policy responsibility almost entirely to the open mail list, and the Assurance Policy was their first challenge.
Progress was slow. In practice, each section had to be argued over, and fights errupted over seemingly trivial details. As one detail would appear important to one person, and trivial to another, there must have been some merit in it. Finally, after some 6 months of discussion, the Assurance Policy entered into DRAFT.
The Assurance Policy has a number of notable features. Firstly, it sets a general standard for the Assurance of individuals. Specifically, the Name is defined, the documents identified, the basic check is laid out, and the points system is established. This finally establishes a benchline for what had been argued in the community for a long time.
Secondly, although it is a firm policy and hard to change, it explicitly splits out a lot of detail into something called the Assurer's Handbook. This is a dynamic wiki document, nominally under control of an Officer. It is argued that because the threats move too quickly for policy deliberations, then much of the day-to-day practice will be better dealt with in a document that is not so heavily controlled by audit provisions.
Thirdly, it establishes the definitions of Assurers and gives authority for the Challenge.
What's in a name? That which we call a rose By any other name would smell as sweet
William Shakespeare
|
Above, we stated fairly baldly that the point of a certificate was to provide your Identity, which might be simply seen as recording, verifying and presenting your name in a certificate. E.g., a recent document said [9]:
The primary purposes [are]: (1) Identify the legal entity that controls a website. Provide a reasonable assurance to the user of an Internet browser that the website the user is accessing is controlled by a specific legal entity identified ....
And further:
The secondary purposes [are] to help establish the legitimacy of a business claiming to operate a website, and to provide a vehicle that can be used to assist in addressing problems related to phishing and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the owner of a website, [they] may help to:(1) Make it more difficult to mount phishing and other online identity fraud attacks using SSL certificates;
(2) Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves and their legitimate websites to users; and
(3) Assist law enforcement in investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject.
|
That is fairly typical of the thinking in the CA industry. Traditionally, the claim made to sell certificates was made in two parts:
But this is just plain wrong. We do not need the name to trade, the seller just needs the money (therefore any credit card is fine) and the buyer needs the goods (therefore any address is fine). With or without the name, these things work fine, and eBay's reputation system seems good evidence of this. The same goes for most other aspects on the net, a good name for a person is simply not needed, although it is more polite than a good number.
|
Afterwards, we might need to chase the person, but the reason is that we want to see them in court. However, getting someone to court is only helped marginally by having the name. What helps more than anything is proximity and reputation. Sadly, the utility of all these things go down, as we get out and on to the net, and names in certificates suffer exactly the same fate as everything else on the net: it is harder to dispute as the distance increases, and transaction costs will force most low value, long distance disputes to be un-heard.
|
By any other name would smell as sweet
|
For example, in the case of "Eros LLC vs John Doe (Tampa)," an Avatar, Volkov Catteneo was pursued and found in real-life [11]. The overriding factors were the location of the person in Texas, the ability for the system of dispute resolution to reach that person, and the desire of the pursuer to chase the person that far. The name was not that important.
|
However, perhaps we can skip the the utility of the name in helping us to get to court, and just look at the forum itself. Classical courts are too expensive over distance, so what alternatives exist? It turns out, quite a lot, and further, CAcert has already put in place a mechanism, its own forum for Arbitration. For that, we turn to the next section.
You can't punish a key. What would you propose doing? Lop a bit off?
Steve Kent
|
As seen above, Audit forced on CAcert a clear exposition of Risks, Liabilities and Obligations, which in turn faced it up to a need to control liabilities, both internally and externally. Externally, liabilities were controlled by disclaiming them, but internally it was felt that in true PKI style, Members should be able to RELY on certificates.
How then was this reliance to be controlled? How were the consequent liabilities to be disputed, allocated, and recovered? Any court case would be too expensive for any Member to think useful, which led CAcert to look at Alternate Dispute Resolution. In the event, it was decided to put in place binding Arbitration amongst Members. A set of rules was written, and at the September 2007 meeting of the Board, the policy was approved [12]. "Out of an abundance of caution," this and other policies were also presented before the Annual General Meeting of the Association, and to the newly-empowered policy group. As of November 2008, seven cases have been dealt with and one is pending [13].
|
Arbitration is a method of dispute resolution that is conducted outside of the normal courts, but is backed up by the normal law which those same courts work to. This law is commonly called The Arbitration Act, an Act passed in most countries [14]. The import of this is that courts are generally at peace with the practice of Arbitration. Indeed, courts will refer cases to Arbitration, and do so happily.
The strength of the Arbitration system in CAcert derives from the Arbitration Act found in most countries. Here is a brief description of the advantages for CAcert:
|
Above, we saw a claim that perhaps the real benefit that users want behind certificates is to get their counterparty into court. Arbitration can be seen as a mighty fine substitute to the more conventional courts, and in this it answers to that real need.
|
The original Assurance Programme has always provided a pretty good basis for verifying the Member's Name. And in its improved version, with a policy, formal Handbook and tested Assurers, it provides a good and solid basis.
But the true strength of Assurance is now found elsewhere than the conventional check on Identity documents. A CAcert certificate now makes five important claims about a holder, taken from the Assurance Policy [15]. They are, briefly:
It is the 4th one that is key here: With the Binding Arbitration clause of the CAcert Community Agreement, the Member has agreed to stand before a peer as respondent, as will the initiator of the dispute, claimant. Typically, many of the systems and policies of the CA are now oriented towards this goal.
In a hopefully fair and open manner, the CAcert Arbitrator will hear the dispute, and deliver a binding ruling. At the Arbitrator's disposal is a list of remedies, from mild to severe: from community work days and loss of status (points) up to €1000 of fines and ultimately ejection.
Accepting all the above, we can finally get to the end of this long path to understand the big shift in Assurance: the Name within the certificate is no longer (as) important for reliance, as CAcert has other methods to encourage Members to behave. To some extent, the Name is now reduced to a cosmetic issue, and this matches the reality of the net far better. In the general Internet use-cases we know of, it is probably not necessary for you or your counterparty to have a detailed, verified Name, but an Assured Member can certainly put it in there if you want.
(As an exercise, the reader may like to work through what happens when disputing a certificate holder without any strong name in it, whether absent or a nickname.)
|
There are limits. An important one is that the possibility of remedies by Arbitration is not necessarily available to all. Let's examine that. The offer made to Internet users states that the person is not permitted to rely on the certificate [NRP-DaL]. Yet, the dispute resolution rules clearly permit that anyone may file a dispute [DRP].
Any parties that are not Users and are not bound by the CPS are given the opportunity to enter into CAcert and be bound by the CPS and these rules of arbitration. If these Non-Related Persons (NRPs) remain outside, their rights and remedies under CAcert's policies and forum are strictly limited to that specified in the Non-Related Persons -- Disclaimer and Licence. NRPs may proceed with Arbitration subject to preliminary orders of the Arbitrator.Superficially, these two provisions seem to be a contradiction, but actually they work together. Although any non-related person can file a dispute into the CAcert forum against a certificate holder, the Arbitrator is not likely to give that person any monetary compensation. If they are not permitted to rely, then, and have still got themselves into harm's way, then they have taken matters out of CAcert's hands and into their own.
Yet, the absence of compensation to the person does not mean the absence of punishment to the Member. Indeed quite the reverse is possible, and the Member could find himself punished according to a list of remedies listed in the rules. Some are benign or soft, such as a day's service to the community or the loss of status (points), but the Arbitrator has the power to fine up to € 1000 or to eject the person from the Community.
There are other incentives which assist Audit immeasurably, and explaining them may help to understand our enthusiasm for the project. As well as the above roles, it can also, as a process and procedure reach into much broader areas: governance, support and diplomacy.
Arbitration as a method of Dual Control. Consider support actions to fix a "lost password" as a trivial case of dual control. It would work this way:
- Bob, a user, mails support to get a new password.
- Alice, the support operator on the day, collects all the information from the user, in the normal way.
- Once she is convinced that she has correctly identified the user, as Bob, she can "file a dispute" on his behalf, against herself.
- Trent, the duty Arbitrator, is then allocated directly to the case. He calls for evidence.
- Trent reads through that which Alice presents, as evidence, and writes and publishes a ruling which instructs the operator to change the password.
- Alice follows the ruling and changes the password. In the appropriate support form, she enters in the ruling date and index number into the field that asks for her authorisation.
- Later on, an audit process scans through all of the password changes, and matches them up to the rulings.
Obviously this process is more complex than the routine act of a support person changing passwords common with user-facing systems. But CAcert online accounts can issue certificates, so changing passwords needs a bit more care. The complexities more or less derive from the requirement for dual control, not from the usage of dispute resolution as a support mechanism.
(Note that this is a hypothetical, CAcert does not currently do this.)
Hence, where there is a requirement for dual control, Arbitration can slot in to fill that need.
|
All Arbitration rulings are by default public. CAcert Members have an incentive for CAcert to be seen to be good, not bad. Further, the principles of the community specifically state, as mentioned above, that We do not act to the detriment of NRPs. These forces encourage a fair amount of interest in the Arbitration project, and seek to keep it working to the benefit of all.
One exception has to be noted: Arbitration is about civil disputes and not criminal cases. In the event of prosecution, a judge will not refer such a case over to Arbitration; but it should be noted that pretty much all of the analysis holds, and CAcert remains in a better position in criminal cases with Arbitration than without.
What then happens if a civil case in Arbitration drifts into criminal matters? Likely, a case will move along and document its findings. A civil case is not a trial, and provides no real protection against a prosecution of the Member. On the other hand, any ruling will be of interest to a court. The ruling should provide greater certainty, and a lesser cost, even to the extent that it may end up contributing much to the expert needs of the later forum. This is a positive for the Community.
What about the other way around: a prosecutor launches the proverbial legal strike against CAcert or the Members? Again, the Arbitrator steps in to help. If the court's order is for information, this cannot be provided in the general case because nobody has authority to provide anything but public information. Hence, anyone subject to a court order is required to file a dispute to get the authority. This becomes an essential dual control on all secrets, helping to keep them safe, and only revealed under proper circumstances.
Likewise, the process for emergency actions and breaches (where the latter might be by any means) benefits. According to the principles of governance, Administrators are not permitted to make changes without controls in place, and that includes installing new patches that might stop attacks. Bad things sometimes happen, and when they do, the rule is that the administrator must act according to best judgement, but must then immediately file dispute against self. The dispute before the Arbitrator then leads to the Arbitrator reviewing the actions, likely delivering a post-event authorisation, and possibly delivering further guidance or even sanctions where events were not well handled.
In practice, then, although the person out on the Internet is not permitted to rely on the certificate, there are substantial and solid reasons why a CAcert certificate can be considered to be a reliable thing.
|
Over time, CAcert's dispute resolution has evolved to fill these roles, some of which are written in as policy or practice, and some of which have evolved into actual cases:
With so many advantages, it is no stretch to see that the dispute resolution system pays for itself in its flexibility. At the time of writing, there have been a handful of disputes on the issue of What's in a Name?, and now one serious dispute on the issue of the closure of an account. The issues were complex, but the Arbitrator surmounted them, and ruled. Others can now follow that ruling and build upon it.
|
There are many disadvantages and these are widely discussed in legal circles. Here are some of the controversies experienced to date:
As we saw above, Arbitration changes the character of Assurance quite a bit. More importantly for this author, it makes questions of auditing the quality of Assurance, and most other areas, much more tractable. Before, auditors had to ponder the imponderable: what identity document is better, are 3 middle names too many, and how do we deal with those foreign characters?
|
Now, Audit can look at whether the system leads to a process of resolution of disputes, and that, once filed, the process leads to a just, fair, efficient, and open result in any hypothetical problem at hand.
Obviously, there are details of how we travel from Membership and Assurance to reliance and usage, and thence to Arbitration and a ruling; these details are not trivial. They might be expensive, in time and resource. There can still be problems in any given case.
Yet, for all these costs, CAcert has surmounted the barriers, has conducted a handful of Arbitrations, and has delivered results, all of which has served the Community well. Arbitration is workable, it is efficient, and complete. The system applies across broad swathes of policy and practice, making the audit process much simpler. Even better, it goes further in reducing the role of the Auditor, as any Community Member can review the rulings. That which is open and is verifiable by the public does not need to be audited.
Perhaps best of all, it has finally given the certificate some sense of the value and pride, promised to it.
|