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

Re: editorial on Photuris



-----BEGIN PGP SIGNED MESSAGE-----

Indeed the issue is how trust is established. PGP has flourished because of
several properties:

o No infrastructure required. Two parties can obtain PGP and communicate as
  soon as they have it installed.

o PGP has a built in direct trust verification system, namely a built-in
  command to generate the MD5 hash of a public key (for easy communication
  over a telephone or other "trusted" channel) as well as a manual that
  explains why you need to do this and how to do it.

o PGP's Web of Trust in effect easily supports several, potentially
  mutually exclusive,  hierarchies. A Name/Key binding can have multiple
  signatures associated with it. If commerce were to use PGP, then I could
  have Visa sign my key and Master Card sign my key. I would still be able to
  use my one key and it would be trusted by both Master Card and Visa without
  Master Card nor Visa having to trust each other (or trust some "higher"
  third party!).

o More to the point, PGP easily facilitates the above.

o PGP supports a mechanism for me to extract my key and send it to you.
  Similarly you can add your signature (after verifying authenticity off
  line) and send me back my key and I can easily incorporate my key (with
  your signature now attached) back into my keyring.

o PGP does not preclude a more formal hierarchy, but it is not limited to one.

In short PGP has been successful because as a program it is a complete
system including not only confidentiality and authentication but the real
tools you need to do key management as well.

Its completeness has permitted people to implement the PGP keyservers for
public key exchange.

The primary complaint I have seen against PGP is that a naive user can be
lulled into believing a message that she shouldn't (i.e., this message is
PGP signed, but unless you *know* that you have my public PGP key, you
really don't know if it is from me [P.S. the same is true of Charles Watt's
PEM formatted messages]). However PGP does attempt to warn people when
uncertified keys are being depended on. If people choose to ignore the
warnings...

Some have proposed that the only answer to this problem is to make it
impossible to use the system (be it PEM/MOSS/SSL etc.) unless you have a
legitimate certificate, removing any discretion from the end user. However
such systems have tended to be constructed of nonobtainium. Legal
agreements are required, many with onerous licensing terms. For example
Apple's AOCE requires the certificate requester to agree in writing (in ink
in front of a notary) to  Apple's software license (which is otherwise a
license of adhesion).

The Netscape Commerce server requires a certificate issued from Version in
order to communicate with people who use Netscape's web browser. However
Verisign isn't under any obligation to give anyone a certificate. In fact
the last time I checked, the Verisign certificate agreement [which may have
changed] didn't guarantee renewal. In theory a company could setup a
Netscape commerce server, get a certificate and then find themselves
suddenly out of the secure web business (assuming that Netscape checks the
certificate validity dates) if a disagreement with Verisign results in
Verisign not signing a renewal certificate.

Now it is also important to understand that none of the above precludes the
use of X.509 or any other format. You can easily build a PGP like
application using X.509 format certificates (they would be bigger and
clunkier then the PGP format because each PGP signature would require its
own certificate). Similarly you can use the PGP format in a product that
requires a strict naming hierarchy. Its just that traditionally X.509
certificates have been associated with nonobtainium certificates and PGP
has been associated with an easy to obtain (modulo export control and other
nonsense) and use program.

Sorry for the length...

                                -Jeff

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMKrS28UtR20Nv5BtAQEhGAQAicdUy3j8dTW8DzFJATLfG4ZgygECOgHT
wXO1vggDqaRTtsYxfvU9M8G0Fu14l6MM7qKeAWpMuPwuy3w01GyL2EU0V24I6EWe
eXUYisI9GxS+A/kPbUqBcYsDLWId1YrpF+8VBMdHvMNmApfq0HvWrFkAPMhf2dGd
jv830g6JDOw=
=goOP
-----END PGP SIGNATURE-----