[182] in WWW Security List Archive
Re: what are realistic threats?
daemon@ATHENA.MIT.EDU (dkearns{TCNET/HR/dkearns}@klaven.t)
Tue Oct 4 19:59:03 1994
From: dkearns{TCNET/HR/dkearns}@klaven.tci.com
Date: Tue, 4 Oct 94 12:14:00 -0600
To: www-security@ns1.rutgers.edu
Reply-To: dkearns{TCNET/HR/dkearns}@klaven.tci.com
>From: SZABO @ SMTP (Nick Szabo) {szabo@netcom.com}
>Date: Tuesday, October 04, 1994 11:20AM
>
>
>Karl Auerbach:
>> Different people have different definitions of "security" and you
>> might not be happy with the author's definition as embedded in his/her
>> program/script even if you can prove you have an authentic copy.
>
>It's important that certificates have a well defined and understood
>scope. "This program has good security" is a possible certificate:
>highly reputated security experts examine and sign off
>a piece of important code, for example. "The person who controls
>the corresponding private key is a good credit risk" is
>another possible certficate: the person's public key, plus the
>text of that claim, signed by a reputable credit agency. What's
>important are the reputation and incentives of the signers, and the
>specific claims they have made in the certificate they are signing.
>If you don't agree with the certifier's definitions of security, or
>good credit risk, or "identity", or whatever other claims they
>might make, or you think they lack an incentive to be straightforward
>about the claim, then (assuming the system hasn't been coerced by law)
>you can reject those claims and ignore the certificate.
>
>The digital signature mechanics simply indicate that we have
>the same copy that was signed and that the person controlling the
>corresponding private key(s) at the time signed it.
>Any other imputation is a matter of judgement and contract, which
>should and will often vary greatly between applications and industries.
>
As I see this, then, there are two parts: the Guarantor and the Guarantee,
the Guarantor's
'signature' indicates his agreement to the Guarantee (i.e., 'I wrote this').
Of course, I'm only familiar with the work of a small percentage of authors
(document or software)
and an even smaller percentage of creditors.
I'd need another Guarantor to approve the Guarantee 'this author is
trustworthy' or
'this software is secure'.
Now, its possible I'm not familiar with this particular Guarantor either.
Its possible that a
third Guarantor could then Guarantee the second was a competent judge of
secure software,
but at some point I'd want to check a well-known, trusted 'third-party-site'
who would guarantee
the integrity of the outermost Guarantor of the software.
It follows, then, that we'll need some hierarchy of 'Guarantors' as well as
a standardized list
of Guarantees - and standards groups to maintain both.
Where will this infrastructure come from?
-dave
+-------------------------------------+
| Dave Kearns
| Manager, Electronic Commerce
| Thomas-Conrad Corp.
| 1908-R Kramer Lane Austin, TX 78758
| (512) 836-1935
| dkearns@klaven.tci.com
| dkearns@tcc [MHS]
| 76704,62 [CompuServe]
| http://www.tci.com/
+-------------------------------------+
