RE: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Fri, 2 Oct 1998, Anders Rundgren wrote:

> Ed Gerck wrote:
>>
>>The first usual misconception here is when people confuse trust in a
>>certificate to trust in a certificate's contents -- too quite
>>different animals. In fact, the first is directly defined under X.509
>>or PKIX but the second depends on the CPS, which depends on each CA,
>>which systematically negate it.
>
>Systematically negate it?
>
>Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
>CA services that issues certificates with contents that can actually be used.  But as I said earlier,
>Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)

Anders:

;-) As I suggested in my earlier msg, let us please leave
water-splashing to the ducks! Looks fun, but no work is done.

Probably you just could not yet read the reference I provided, which
is at http://143.106.29.39/certover.pdf -- "Overview of Certification
Systems: X.509, CA, PGP and SKIP". There is also a (older but more
complete) HTML version at cert.htm

However, the very end of its section on X.509 has the following text,
which I think will address your concerns -- please read the rest of
the paper for the context. You can also check the "Misconception"
series in the mcg-talk archives and the posting "Is there a business
for CAs?" -- the address is http://143.106.29.39/emails.htm


====================================================================
....[snip]

This paper reviews the three most common certification methods in use
today, which are based on X.509 Certificates and Certification
Authorities, PGP and, SKIP. These methods are studied from a systemic
point of view. The main motivations for this paper are: (i) Conduct a
comparative review of the three methods, (ii) Unify a set of
references to the most important issues in certification and
encryption, as they are related to Internet needs and recent
governmental policies, (iii) Provide a basis for the evaluation of
other certification solutions available or to be developed, (iv)
Identify room for improvements on the current security level of
certification, that could be dealt with by other methods, (v) Access
the impact on Internet transaction security due to the security
control policy needs of Governments currently actively promoting such
policy solutions.

....[snip]

In summary, there are many reasons that may jeopardize a
"certificate", create a weak link or, give the wrong contextual clues
for on-the-spot decision making.

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:

     VERISIGN DISCLAIMS ANY WARRANTIES WITH RESPECT TO THE SERVICES
     PROVIDED BY VERISIGN HEREUNDER INCLUDING WITHOUT LIMITATION ANY
     AND ALL IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
     PARTICULAR PURPOSE. VERISIGN MAKES NO REPRESENTATION OR WARRANTY
     THAT ANY CA OR USER TO WHICH IT HAS ISSUED A DIGITAL ID IN
     THE VERISIGN SECURE SERVER HIERARCHY IS IN FACT THE PERSON OR
     ORGANIZATION IT CLAIMS TO BE WITH RESPECT TO THE INFORMATION
     SUPPLIED TO VERISIGN. VERISIGN MAKES NO ASSURANCES OF THE
     ACCURACY, AUTHENTICITY, INTEGRITY, OR RELIABILITY OF
     INFORMATION CONTAINED IN DIGITAL IDS OR IN CRLs COMPILED,
     PUBLISHED OR DISSEMINATED BY VERISIGN, OR OF THE
     RESULTS OF CRYPTOGRAPHIC METHODS IMPLEMENTED.

However, the issuer's disclaimer (i.e., the CA's) is generally not
visible in the certificate itself, for all browsers and all
X.509 implementations. 

Further, such CA disclaimers are part of the CA's CPS (Certification
Practice Statement, which is outside the scope of X.509 and
constitutes the governing law that the CA presents to potential
clients). Thus, it can be seen as a legally-enforced way to reduce
deliverables to almost zero -- which is an accepted legal practice to
effectively reduce liability to zero. So, the point is not so much
that CAs deliver a product with zero warranty (which could be
disputed in court even in countries with common-law systems) but that
CAs are delivering a product with almost zero content (which any
court would accept as envolving almost zero liability) -- as it is
clearly exemplified in the second and third sentences of the above
disclaimer ("...MAKES NO REPRESENTATION ..." and "...MAKES NO
ASSURANCES ...").

Actually, the content of a CA's services in relationship to the
subject's data is not zero because there are two items that X.509
mandates and that a CA must deliver in a certificate without content
disclaimers (but, which may still be limited in scope by the CPS):
(i) that the subject's public-key has a working private-key
counterpart elsewhere (with no warranties that the public/private key
pair is not artifically weakened, that it is actually in the
possession of the named subject and that no one else has obtained a
copy of it), and (ii) that the subject's DN is unique to that CA
(with no warranties that such DN contains the actual subject's name,
location or that the subject even exists or has a correctly spelled
name -- as in "Internet Serices"). There are other items in the
certificate which have no relationship to the data supplied by the
subject but which are necessary for the proper use of the certificate
as a secure transport for information in the X.509 model, such as its
serial number, date of issuance, validity, the CA's signature, etc.,
which usually also carry limited CPS warranties (e.g., as in the case
of fraud, computer viruses, etc.) that may further jeopardize the
secure use of the certificate, without the user being even aware of
it.

Now, having cited Verisign's disclaimer, it is important to
understand its reasoning and need. It does not say that Verisign has
no warranty on its services or that it does not take any liability on
them. It only says that Verisign has no warranties and accepts no
liability for services that Verisign does not recognize it provides.
The fact that Verisign does not provide what perhaps the majority may
think they provide is another point altogether. The solution is,
perhaps, much more to educate the majority than to expect a company
to do what is maybe technically unfeasible in X.509 terms.  Thus, in
the author's opinion, Verisign's CPS is not at all at odds with X.509
or legislation -- so, it could very well be an example to be copied.
Maybe, it just truly represents the maximum one commercially and
technically could wish for in X.509's and CPS's terms.

Thus, for any generic CA one might expect a similar reasoning.
Indeed, if the only thing that a CA does (as per X.509) is to
challenge the subscriber's private-key in order to bind the
corresponding public-key with the subscriber's DN and, if it signs
the certificate with a CPS that says that any other data are being
copied as received but have not been verified (and have thus no
warranty) then the CA has no responsibility for the contents of the
certificate -- save the positive acknowledgement that the public-key
did have a counterpart when it was linked to that DN (where the CPS
could further provide exceptions for frauds, virus, MITM attacks,
etc.).

One may ask, why are such content limitations and disclaimers
necessary for certificates? First, a certificate is not like a car
that has a limited liablity in space and time (after all, a car is a
localized entity that can contain a limited number of people and only
one driver). A certificate can be endlessly multiplied and
simultaneously presented in a planet-wide area. Certificates are used
without limit in a chain of events, which can include other fully
unrelated certificates and people. With the growing attitude of
seeking large legal compensation for one's lack of foresight, the
liability pyramid created by a lesser disclaimer could easily extend
to the CA's client's clients and so on.

Insurance protection may help here, but there are several issues that
must be touched upon. The use of insurance always signals lack of
knowledge -- so it clearly cannot replace it. Further, there is no
insurance needed for a sure event and there is no insurance possible
for a sure risk. If a user (ie, a CA subscriber) is going to for pay
insurance to cover his liabilities and the CA's liabilities (which is
what it amounts to), then responsibility has gone full-circle and is
now only in the user's hands -- both to get adequate coverage and to
pay for it. While the CA has zero risk and cashes in as the middleman
between the user and the insurance companies. However, that does not
solve the risk problem for the user either, because one cannot make
the whole world sign up one huge insurance policy -- so the user and
the CA may be protected by the insurance policy that the user has
bought with their names as beneficiaries but that does not protect a
third-party (ie, the rest of the world). Last, since CA auditing does
not help here, then insurance does not have a reliable risk estimator
either, even for the CA subscriber.

Regarding recent legislation efforts, such as in Utah (US), Illinois
(US) and other legislation, it is clear form the above discussion
that demanding broader warrants by law can be self-defeating because
CAs may then be forced to reduce the deliverables to zero -- instead
of coming out and providing for more warranties. There simply is a
limit to what X.509 and the CA paradigm can offer regarding legal
certificate reliance and -- most importantly and often confused with
the former -- legal certificate content reliance. Law cannot push the
technical envelope of X.509.

When confronted with risk situations, a normal business solution is
to rely on auditing. However, auditing of a CA's certificates is also
a difficult, if not impossible, task. This is due to X.509, which
allows CA's practices and policies to be built upon islands of
self-regulation exactly on the most important issues of trust and
trust management. 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."

Thus, a X.509 certificate is essentially a bag of bytes, which
meaning and validity strongly depends on the CA. Moreover, in legal
reliance terms, one may trust the confirmation procedures of the CA
during certificate reliance, but one cannot rely upon them for other
than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes.

Last, when one waches for some time the different mailing lists that
collects doubts and questions on certification systems from users or,
when one reads the majority of the newspaper or magazine articles on
the subject, one cannot help but perceive a pervailing feeling in the
user community to the effect that a certificate is magically infused
with trustworthiness -- which would imply a deterministic and
absolute view of certification. For example, as one user wrote:
"Please provide me with a list of all trusted CAs so that I can enter
those certificates into my browser.", few understand that trust must
be evaluated relative to the user -- the party at risk. Thus, the
very names Trusted Third Party or trusted CA raise already several
questions:

- in relationship to whom? 
- trusted by whom? 
- trusted for what? 
- trusted for how long? 
-- etc. 

How are these questions answered? Clearly, by each user (ie, verifier
or, relying party -- who is at risk) in its own domain, references
and terms. This means that certificates are essentially statements
from a CA, not fact, and that meaning and trust on a certificate
(like beauty) is in the eyes of the beholder, i.e., depends on each
user.

==================================================================


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