[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The role of trust in certification

All,

(mild apologies for lurking so long before speaking up)

Uri wrote

>Certificate merely tells: "...and what it says is true - I attest to it."
>
>A question might be - what exactly do the certificates "certify"?
>Identities? If so - how much of it? Is it "Joe Shmoe"? Or "Joe
>Shmoe who lives at ..."? Or "Joe Shmoe who lives at..., works
>at ... and has been paying his loans well till now"?
>
>Because I may well "trust" that the person behind that certified key
>indeed is Joe Shmoe - but unless I already have a policy installed
>that tells me precisely what Joe Shmoe is allowed to do (or to
>receive from me), just "knowing" the identity gives me little.
>I need more [certified] information...

This is a big part of the problem.  What a certificate actually *says*
is something like

"By the power vested in me, I now declare this text string and this bit string
'name' and 'key'.  What RSA has joined, let no man put asunder".

Now, of course, in order to know what the certificate *attests to*, you
have to ask "what were the vows"?

But this question is not answered in the certificate itself -- you have
to find out what church the ceremony was performed in and look at the order
of service (something like a Certification Practice statement).

Because of this, certificates which are lexically identical except for the
identity of the signing CA can *attest* to quite different things while
*saying* the same thing -- all on the basis of out-of-band contextual
information (CPS terms, CA contract with cert. acceptor, etc...).

When I rely on a certificate, I am asked to enter into two *trust*
relationships:

(1) I am asked to trust that the authority represented by the identity of the
signing
    CA has done all the things its Certification Practice statement says it
will do.

(2) I am asked to trust that acceptor of the Certificate will honor the vows
that
    both parties to the certificate (name *and* key) took.

    What are these vows?  Well, of course, it will vary as noted above.  But
    generally, they are something like:

    "'name', do you agree to honor and cherish 'key'?" (i.e. does the
Certificate
    acceptor agree not to repudiate actions signed by the private key, and to
    keep it private?)

    "'key', do you agree to honor and obey 'name'?" (i.e. does the Certificate
    acceptor agree to use the key to sign using the key only in situations
    where there is an intent to bind the party referred to by the name into
    some relationship?)

Note that I'm not *trusting* either the *Certificate* or the *CA* here -- I'm
trusting the *people* who own the CA and the *people* to whom the Certificate
has been issued (we encourage confusion here by referring to both the
device which issues certificates and the company which operates that device
by the same name: CA). What am I trusting them to do?  Just what they say
they'll
do; I'm trusting the CA owners to live up to their obligations stated in the
CPS, and I'm trusting the Certificate acceptor to honor the vows he took on
behalf
of 'name' and 'key' when he requested the certificate.  (I may also have to
trust the Certificate acceptor to honor the terms put forth in a document he
signed with the private key; that's a third trust relationship.)

All of this discussion has related to what a Certificate *attests to*.   A
logical question would be, why is what a Certificate *says* important here?

I think the answer is that it's what a Certificate *says* that establishes
a historical context for evaluating trust decisions.  The first time I receive
a certificate, my trust in the parties "behind" the certificate is based on
blind faith.

The second and subsequent times I rely on the same certificate, the binding
between the CA key and the acceptor key, and the binding between the acceptor
key and a signed document, combine to give me confidence (assuming I believe
in the strength of cryptography; a whole other discussion) that I'm dealing
with the *same* parties with whom I have a past history.  This allows me
to make trust decisions in the same way I do in the real world with people
I actually know: on the basis of my observations of their past behavior.

You'll note that implicit in this is a criticism of Ed's definition of trust
as knowledge.  I think it's an interesting analytic model but clearly not
"true" in any real-world sense.   Trust is certainly by both the intuitive
and the dictionary definitions not knowledge, but rather *belief* -- that
another party will act in a certain desired way.


--bob

Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax:    +1 (512) 838-0156
Post:    11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: blakley@us.ibm.com
Follow-Ups: