1995-10-10 - Re: Certificate proposal

Header Data

From: Bob Smart <smart@mel.dit.csiro.au>
To: Hal <hfinney@shell.portal.com>
Message Hash: 36f27d333bfaf9d372c08e51b785bc406c6e5e7c2d5bb6c5b7c5959c854fea65
Message ID: <199510100002.AA01774@shark.mel.dit.csiro.au>
Reply To: <199510092316.QAA09588@jobe.shell.portal.com>
UTC Datetime: 1995-10-10 00:02:51 UTC
Raw Date: Mon, 9 Oct 95 17:02:51 PDT

Raw message

From: Bob Smart <smart@mel.dit.csiro.au>
Date: Mon, 9 Oct 95 17:02:51 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re: Certificate proposal
In-Reply-To: <199510092316.QAA09588@jobe.shell.portal.com>
Message-ID: <199510100002.AA01774@shark.mel.dit.csiro.au>
MIME-Version: 1.0
Content-Type: text/plain


 >  Hence the problem has no solution and we should not
 > waste much time on it.

Exactly. If a public key ONLY has an existence in cyberspace (as per
Pr0duct Cipher) then it is impossible to prove that they aren't
surrounded by a MITM cloud which is also seeing everything they
see without them knowing it.

It is important to be aware of this. However the importance is
perhaps mitigated by the following considerations:

1. Surrounding someone with such an MITM cloud is so hard as to
   be impossible for practical purposes. This will be more true
   if the person trying to establish a cyberspace identity can
   prove that they move around physically and use different service
   providers at different times [but then again perhaps if you
   do that you cease to be a purely cyberspace entity].

2. If the other end of the communication is a purely cyberspace
   entity then you can't possibly establish the sort of relationship
   which would enduce you to send them anything really secret. The
   possibility that there might be a baddy playing MITM is 
   infinitesimal compared to the probability that the other end
   is itself a baddy.

The time you will want to deal with a cyberspace entity is where
you are taking no risks and they are taking all the risks.
This will hopefully be the case when we are a seller and they are
the buyer. As long as we get the digital cash we don't care who
they are.

Apart from that we will always want some certificate that links the
public key to something in the real world. The point of the
key-centric approach is that that doesn't have to be a name or
something that contains a name. If we want to make sure the key
belongs to the person you were talking to last night then maybe you'd
like some biometric data: "five foot two, eyes of blue,...". And
of course the certificate is useless unless it is signed by a key
that we trust for that purpose.

Bob Smart

P.S. I hope my earlier posting were not interpreted as being critical
of the IPSEC effort. I strongly support it. It would be silly to
go to them and say "hold everything I think we need a whole new
security architecture". That is something for the future that we
are only just starting to think about. However I think the IPSEC
work confirms the difficulties of the current "name first then
key" approach. Whenever it is incorporated in any protocol from
network layer to application it makes the protocol at least twice
as complex and at least twice as hard to manage.





Thread