[3638] in cryptography@c2.net mail archive
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital
daemon@ATHENA.MIT.EDU (Ed Gerck)
Thu Nov 12 22:42:40 1998
Date: Thu, 12 Nov 1998 18:55:11 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Dan Geer <geer@world.std.com>
cc: cryptography@c2.net, dtd@world.std.com
In-Reply-To: <199811120425.AA06672@world.std.com>
On Wed, 11 Nov 1998, Dan Geer wrote:
>> Dan previously wrote:
>>> The full cost of revocation testing is proportional to the square of
>>> the depth of the issuance hierarchy.
>>
> Anonymous replied:
>>
>>The first statement is false. Revocation testing is not proportional to
>>the square of the depth of the issuance hierarchy. If you had, say, a 5
>>level deep issuance chain, you do not need to check 25 revocation lists.
>>You only need to check 5.
>
>i'm sorry, gentle reader, but you are mistaken. you see, we are making
>an obvious assumption that you, like most of the industry, have missed:
Dan:
I could not read that assumption in your excerpt which was posted
here. But, notwithstanding its late entry ... still no cigar.
You see, you have to make your mind. If you believe that CAs are
inept to revoke what they have issued and they warrant -- fine. If
you believe that Revoking Authorities (and, please, do not christen
them RAs since that acronym was already differently defined in X.509
proper) will be able to do that better in their own locality -- fine.
But, do not mix apples with speedboats. After all, which revocation
is a Denial of Service attack or a false alarm? To you, such cannot
happen and you are effectively believing both -- that is why you get
N times N as I can quickly summarize from all your graphs.
While this may seem to conduct to a Verifier-centric PKI -- in
contrast to an Issuer-centric PKI built by CAs -- the internal
inconsistencies cannot resist simple analysis (which I can present if
useful to you).
>
>>> ...threat to strong security apparati of having them undermined by
>>> key escrow.
>>
>> ...No proposal for key escrow asks for signature keys to be escrowed.
>> Only encryption keys are escrowed. Key escrow threatens secrecy but
>> not authorization. It is not an issue for electronic commerce.
>
>some very large commercial customers for authorization software _do_
>want effective secrecy for authorization-certificates. it is important
>in those markets to keep a customer's access-rights confidential.
>similarly, some financial and securities transactions will legitimately
>involve parties who want strong privacy, or who even may legally be
>required to remain unidentified, at least temporarily. these kinds of
>confidentiality would be threatened by the escrow of encryption-keys.
I have nothing in favor of mandatory key-escrow but "secrecy for
authorization-certificates", "keep customer's access-rights
confidential" and "remain unidentified" are issues for which
encryption is simply not needed. To say otherwise is misleading.
But, the presentation has IMO other problems.
The first problem is when Dan posits and defines "trust management".
IMO, this was the basic mistake that led Dan to subsumm trust into
risk. There is and there can be no system-wide "trust management",
since trust MUST be locally qualified (ie, subjectively by each
user). If trust is not evaluated autonomously by any user then it is
not trust, it is constraint. Can you say "subjectivity management" is
how subjectivity is created, propagated, circumscribed, stored,
exchanged, accounted for, recalled and adjudicated? No. It is an
oxymoron -- just like "trust management". You cannot manage what
others are free to define, at their will.
The second problem occurs when Dan perceives that trust cannot be
"managed" at all and presents risk management as the dual (whatever
that word may mean in the text) of "trust management" -- and more
important than trust itself. Of course, the dual of an oxymoron does
not exist, even though "risk management" exists, can be well-defined
but with due care for "locality", is very useful and can be very
profitable as insurance companies have been doing it for centuries.
A next problem is when it considers trust to be a synomym for
"conjecture" -- as it considers trust to be the dual (again, whatever
that word may mean) to risk -- since all risks are essentially
conjectures.
This may lead also (though not explicit in Dan's quoted section) to
the questionable notion that risk can be objectively assessed by
"financial service providers" -- a point clearly answered in the
negative by the current stock-exchange crisis.
However, IMO the presentation is correct when it considers that
"trust management" cannot work and focuses on "risk management" as a
useful concept.
This is however undermined by the absence of a working basis for
communication and security. Which need is usually designated by
"qualified reliance on received information" -- or trust as the
concept of trust is, originally, before being confused with
conjecture, shadow of a doubt, authorization, guess, belief and even
the dual of risk.
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 ---
