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

Re: Man in the middle attacks

Bob Jueneman writes:
>It might be a bit of a reach, but I think that I could claim that certificates
>provide a mechanism for some third party to provide confirmation to a relying
>party as to the "role" that the user who possesses the corresponding private
>key claims to have.  This role may be implicit, by virtue of the name (an
>daddress, etc., if present), or it may be explicit in the case of a role name
>or particular credential that is included in the certificate by the CA.

"Provide confirmation" seems a little weak, open to interpretation.

If anything, a certifying agent is a third party (representing itself as)
willing to share some degree of liability in the use of a given key for a
given purpose.  A certificate is a cyboreal instantiation of this limited
liability-shift.  The extent to which the relying party believes it can
seek redress via this agent (when things go bad) determines the extent to
which the key gains trust.  Just what the certifying agent requires of the
key-holder to hedge its liability, be it retinal scan (Identity based) or
key-reputation (history of trusted transactions) or blind faith seems, at
first blush, to be of little interest to the relying party.

On close inspection, the following distinction may be independent of
"ID-based vs Key-centric" but I tend to associate them along these lines:

In the (standard) "Policy-Statement Model" a CA says to a relying party:

  "Trust in my certification of this key&meaning because I demanded (birth certificate, fingerprints, bone marrow, key-history, etc.) of the presumed key-holder.  Use at your own risk."

In the "Liability-Statement Model" a CA says to a relying party:

  "Trust in my certification of this key&meaning because I accept liability
up to $N (or other redress) on these limited transactions.  How I satisfied
my risks in doing so are my business."

In the latter case, it is more important to bind a warm body to the CA than
to the key it is certifying, (at least in many situations.)

>With respect to the CRL issue, assuming that people are not egregiously
>careless with their keys, the most common reason for a CRL in this environment
>is the change of status. the person who is identified is no longer at that
>address, is no longer a member of the organization, or no longer has the role
>capability that was previously assigned. In this case the key holder has
>nothing whatsoever to say about the revocation, as it is performed unilaterally
>by the CA to protect the CA (and any relying parties) _from_ the key holder,
>who might want to abuse her former privilege.

I am very interested in seeing Carl Ellison's promised formalization of
short-term certificates vis-a-vis CRL's in this light.  As I understand it,
the CA would reissue (or fail to reissue) a new short-term cert to the transaction initator (key-holder) at the time of the attempted transaction,
to the same (semantic) effect.

>However, it seems to me that the discussion has been excessively narrow, and
>involves only person-to-person e-mail types of interactions. The entire notion
>of key-centric identification falls apart, IMHO, when you start looking at
>certificates for clients and servers, for electronic commerce, and other
>applications where a human has not been involved in a series of transactions.

As long as there are lawyers and high-risk transactions, Key-Centricity may
have to resolve to CBU(Carbon-Based-Unit)-Centricity somewhere up the chain,
although the resolved identity may be that of some liability-bearing agent
rather than that of the key-holder/presenter.

Alternately, the future may establish certain persistent CS presences that
offer more reality (or reliability) than many Real-World ones.

Apologies for re-ordering your text somewhat, and thank you for being a
consistent voice of reason on the pkix list.

>
>Bob
>
>Robert R. Jueneman
>GTE Laboratories
>40 Sylvan Road
>Waltham, MA 02254
>Jueneman@gte.com
>1-617/466-2820
>
>"The opinions expressed are my own, and may not
>reflect the official position of GTE, if any, on this subject."

___TONY___

Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL