1995-10-09 - Re: Certificate proposal

Header Data

From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: 26ad5a38d59604dca4337866d2392c48bef3f217b41b09c4f76d6c9c21228d17
Message ID: <199510091646.JAA29034@jobe.shell.portal.com>
Reply To: <199510091558.IAA05131@ix6.ix.netcom.com>
UTC Datetime: 1995-10-09 16:47:24 UTC
Raw Date: Mon, 9 Oct 95 09:47:24 PDT

Raw message

From: Hal <hfinney@shell.portal.com>
Date: Mon, 9 Oct 95 09:47:24 PDT
To: cypherpunks@toad.com
Subject: Re: Certificate proposal
In-Reply-To: <199510091558.IAA05131@ix6.ix.netcom.com>
Message-ID: <199510091646.JAA29034@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Bill Stewart <stewarts@ix.netcom.com> writes:
>This doesn't necessarily eliminate certificates - while you have a signed
>statement from Alice's key that she uses Bank Account X, and a signed statement
>from Alice's key authorizing transfer of $D from Bank Account X to Bank
>Account Y,
>the Bank, or a customer, may refuse to accept the request unless there's 
>a signed statement from the Bank's key that Alice's key uses Account X.
>None of these need Alice's name, or for that matter the Bank's, as long as
>there's
>also a signed attribute statement from the Bank's key that it's a bank, etc. 
>The meaning of the certificates changes a bit, but there's still a certificate
>from the bank binding Alice's Key to Alice's Bank Account.

I can see using keys with attributes in this way, for credentials or as
other forms of authorization.  But what about for communications privacy?
What is the attribute that tells you that using this key will prevent
eavesdropping?

Hal





Thread