Common misconception #10. was RE: NEW Data type for certificate

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Wed, 7 Oct 1998, Phillip M Hallam-Baker wrote:

> Ed Gerck wrote;
>> The uncertainty reaches a point of almost uselessness, where CAs
>> usually explicitly state in the certification contracts that the CA
>> is exempt of all or almost all responsibility regarding the
>> "certificate", its accuracy and its data. For example:
>
>Taking one part of a contract in isolation is misleading. The VeriSign
>contract has a 'disclaim all implied warranties clause', in other words
>it states that the only warranties provided are those explicitly stated.
>

Phill:

Which are zilch to the cert user, as Verisign's CPS affirm. Of
course, I am not talking about the cert subscriber (that has a
contract with Verisign and a limited warranty) but I am talking about
a general cert user -- who is not privy with that contract, at all,
and which is denied any liability from Verisign.

If I make an offer to the whole world, capable of acceptance without
communication by mere conduct, I can be contractually bound.  The
classical example was the 19th century case of the Carbolic Smoke
Ball Company, which advertised an offer of money to any purchaser of
its product (from a retailer, not from the advertising manufacturer)
who contracted influenza after using it.  A purchaser sued
successfully for the money.

The same principle governs modern cheque guarantee cards.  The bank
promises anyone who accepts a cheque covered by the card that it will
honour the cheque.  The bank can be compelled to do so. 

So a CA who promises users that its certificates are correct can be
sued by a user. 

Or, a CA that promises users that its CRLS are correct can be sued by
a user.

That does not undermine my conclusion, however, because CAs are ever
so careful that neither their certificates nor their CPSs contain any
promise open for acceptance in the way I have described above -- or
in the way that you have described -- or in the way that users
mistakenly may imagine.

It is that fact, rather than the impossibility of such a promise
being binding, that protects the CA. 

This point is also contained, albeit more mildly, in my posting on
"If there is a business for CAs" (archives for mcg-talk, cert-talk,
e-carm, etc) and I thank Nicholas Bohm for the legal input on it. It
is also in the Overview paper at certover.pdf.

This is common misconception #10:

  CAs have subscribers and users. Users have no contract to
  CAs and are specifically excluded from any warranty or liability
  by commercial CAs very well-written an public CPSs -- even though
  users are called "relying-parties" in such CPSs. However, users
  must understand that they are a "relying-party"  of their own due
  dilligence.


>The explicitly stated warranty consists of NetSure insurance in a sum
>that varies from $1,000 to $100,000 depending on the certificate
>category. If necessary higher sums could be agreed. This is real
>insurance underwritten by a leading insurer.

The NetSure insurance only applies to Verisign's subscribers -- who
pay for the insurance and are so insured ;-)

It does NOT apply to the world at large, the user, who is not privy
to the contract between Verisign and the subscriber. You would need
the whole world to sign and pay into that NetSure policy in order to
make it begin to be useful to users.. not a bad perspective for some,
but unlikely.

Further, just to make it clear why you cannot fight open risks with
insurance, suppose that 1,000 users have problems with just 1 cert
for ACME, issued by Verisign and insured by NetSure. I ask:

- Who is laible for what?

- Who should each of the 1,000 users sue: ACME, Verisign, the insurer
or, all?

- How much is each of the 1,000 users entitled to claim under
NetSure: the full certificate's insurance for each (thus, suppose,
1,000 x $1,000) or a rate of the total insurance (say $1,000 divided
by 1,000)?

- Who pays what NetSure does not pay but each 1,000 users will
certainly claim?


Thus, it is not misleading to single out that part, since that part
is what negates the user's rigths.

But, I am sure we all know this. Especially the guys that calculated
the NetSure insurance coverage and its exceptions, as well as the
guys that wrote Verisign's CPS.

So -- why the fuss? Perhaps, it is intersting to view common
misconception #10 under a different light. It was very well stated by
a Harvard-graduated lawyer, who declared:

 > CAs and PKI rely on that same sort of systems trust.  You trust
 > that the CA, as an expert system, will do the identify
 > verification, certification revocation, etc. properly.  It's
 > analogous to when you trust that the architect/civil engineer who
 > designed your house (and who are part of a system of education,  
 > licensing, and bureaucratic approval) did it properly and  don't
 > worry about your house falling down.
 
To which I publicly responded, with:

 The analogy you point out does NOT exist and this is a common
 misconception. A relying-party (aka, the cert user) cannot rely upon
 the CA as a house owner relies upon the expert engineer he hired,   
 for several reasons.
 
 First, because there is no contract between a user and a CA while
 the engineer was hired by the house owner or, in other words,
 because the person who pays for the certificate is not the one who
 relies on it. Second, because it is generally accepted that Internet
 traffic is subject to so many possible sources of disturbance
 (willingful or by chance) in so many possible routes that a CA
 cannot present a guarantee of correct results, just of correct
 methods -- which is also law doctrine for consultation work and data
 processing in general. Third, because a certificate is an open-ended
 risk.  Fourth, because certificates cannot really be revoked, and so
 represent an open assignment.  For a list of 16+ causes, you can
 check http://www.mcg.org.br/cert.htm

One other cause is that Verisign denies warranties to the public at
large -- as commented at the top.

Clearly, for any CA the majority of relationships is, albeit
indirectly, defined by CA/user. The number of CA/subscriber cases is
much smaller. This highlights the importance of this issue, since
users are also the ones that must primarily weigh potential losses.

Further, it is also clear that users may hold the subscribers to be
responsible. However, if the subscriber publicly denies any liability
to anyone in the world, then a user may also have only its own due
dilligence to rely upon.

>
>
>> As publicly declared by Phillip Hallam-Baker, a
>> Verisign consultant, not only are the CPSs indeed different and
>> self-made by each CA but they are not designed to be audited, either:
>> "There is not as yet a defined standard for CA practices against
>> which a company may be audited. In effect each company states their
>> own practices in their Certificate Practices Statement (CPS). The CPS
>> is not a document designed for auditing use however. It describes a
>> 'specification', it does not describe details which may be checked by
>> a third party in a systematic manner."
>
>Here you are quoting me out of context. This was in the context of 
>your argument concerning the use of a standardized audit statement. 

I provided the full reference, which was in hypertext under your
name and as reference [Bak98] in http://www.mcg.org.br/certover.pdf.
As referenced in: (long URL)

http://www.mcg.org.br/cgi-bin/lwg-mcg/MCG-TALK/archives/mcg/date/article-379.html

and anyone could search the archives for the full thread.

>
>Taking off the cuff statements out of mailing list exchanges and
>quoting them verbatim offline without checking the context seems 
>somewhat odd behaviour.

As above, that is not the case. The reader can go to the original
thread and check the full contexts of all your messages -- which IMO
will not change anything in that isolated paragraph. Now, if you want
to imply that public mailing lists are not useful to provide
meaningful information without further checking, then I must agree as
we see how much misinformation is oftentimes put out through these
channels. Which we must oftentimes weed out and just get what seems
to be fitting to our own intelligence. Perhaps, this posting also
exemplifies that.

However, if you feel that you can issue a more accurate statement,
then I will be pleased to change them in all the certover.pdf,
certover.ps and cert.htm.htm files -- which have BTW been downloaded
more than 55,000 times in the last year and are cited in some books
and thesis on the subject.

 >
>I was arguing that before you could use 'audit statements' in the
>manner you envisioned there had to be agreement on audit standards.
>Work on audit standards for a CPS is taking place. It is thus entirely
>misleading to take a specific objection to a specific use of auditing
>for a specirfic purpose and conclude that no CPS can ever be audited.
>

But, not the way they are -- and that was what you yourself wrote in
the quote above. Now, I ask: what does a subscriber buy from Verisign
today -- a cert issued acording to today's CPS that we both agree
cannot be audited or, based on a future Verisign's CPS? And, I also
ask: What should we discuss -- today's CPS risks or risks of future
CPSs we do not know of?

>
>Saying that a CPS issued by BongoCert Inc. may not necessarily prove
>to be auditable is not the same as saying that 'A CPS is not designed
>to be audited'. In fact a CPS can be designed to be auditable and
>the ability to conduct an audit may be considered a quality differentiator
>between CPSs.
>
>Rather than 'does not describe' I would instead restate this as
>'does not necessarily describe'.
>

Let me comment by parts. The relevant section of your quote began
with:

>>"In effect each company states their own practices in their
>> Certificate Practices Statement (CPS)." 

This means that unless we believe in serendipity as a valid work tool
then we should expect that CPSs from different CAs do not
interoperate. This reflects BTW a basic flaw of laissez-faire
certification systems such as X.509 and PKIX, exactly where we would
need interoperation -- the semantic rules that certificate issuance
must obey are not defined by the standard but ad hoc by each company.
Who cares that the syntatic rules are clear (ahem...)  in the
standard? Is that all?

>>"The CPS is not a document designed for auditing use however." 

Clear -- like a car is not designed to fly, and does not fly. I also
think that if a CPS would allow what it is not designed to do (as you
seem to imply in your comment above) then that is a security flaw,
by itself no? I mean, what other unthought-of properties could one
spelunk from it? Will such "easter eggs" be good or bad for me? Meet
you in court, you say ....

>>"It describes a 'specification', it does not describe details which
>>may be checked by a third party in a systematic manner."

It says "it does not describe" and you want to change to "it does not
necessarily describe". Fine. However, are we not again relying on
serendipity? And, as Descartes affirmed: "Doubt until you have proof"
means that I can surely doubt such statement will ever support the
exsitence of even ONE auditable CPS, right?


>
>The problem I believe I was having with your argument was that the
>invocation of 'auditors' appeared to be used as a panacea as if the
>statement 'I have been audited' translated to the conclusion 'He is 
>trustworthy' without taking account of how the audit was performed,
>who performed it and what the objective of the audit was.
>
I do not think that can be deduced from any of my postings or
articles. Nor inferred. Should I be bound by a word I did not say? 

On the contrary, my posting considerably stressed that any reliance
derived from trust must depend on the exact underlying terms and
rules that support such trust:

 Thus, in legal reliance terms, one trusts the name confirmation
 procedures of the CA during certificate reliance, but one cannot
 rely upon the name for other than its value as a representation of
 the CA's authentication management act expressed in the CA's own
 terms and rules.


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
 --- Meta-certificate Group Member -- http://www.mcg.org.br ---