1995-08-17 - Re: Object Oriented Crypto API

Header Data

From: monty.harder@famend.com (MONTY HARDER)
To: CYPHERPUNKS@toad.com
Message Hash: c045b615a57c72f52a230c1c819aa4fe8f4b11b9503b00ea6f14fc24d024fda4
Message ID: <8AF4269.000300032B.uuout@famend.com>
Reply To: N/A
UTC Datetime: 1995-08-17 00:39:25 UTC
Raw Date: Wed, 16 Aug 95 17:39:25 PDT

Raw message

From: monty.harder@famend.com (MONTY HARDER)
Date: Wed, 16 Aug 95 17:39:25 PDT
To: CYPHERPUNKS@toad.com
Subject: Re: Object Oriented Crypto API
Message-ID: <8AF4269.000300032B.uuout@famend.com>
MIME-Version: 1.0
Content-Type: text/plain


RC> anything without having to know anything about those formats at all.

  Yes. We need to be able to drop in new algorithms, because nobody
knows what new attacks will be developed.

RC> a Universal Resource Name (URN) for key identification. Perhaps
RC> "key://keyserver.domain/keyid" would be better.

  Need to expand the concept of a key just a bit here. Your URL for keys
needs to map to a hierarchy of keys that apply to different facets of a
person's life, (casual vs. sensitive, personal vs. business) as well as
to different encryption engines. The pubkey I have in the keyserver for
the RSA algorithm will not work if you want to use the FOO algorithm
instead.

  Rather than replicating the entire structure of keys for each new
algorithm that comes along, there should be a standard protocol for
requesting these various key types from the same "place".



 * I can't find where to put the milk in my "cereal" port.
---
 * Monster@FAmend.Com *    





Thread