From: A Loose Affiliation of Millionaires and Billionaires and Babies <cactus@hks.net>
Date: Thu, 9 Feb 95 16:57:51 PST
To: cypherpunks@toad.com
Subject: Key management in Hastur
Message-ID: <199502092115.QAA11291@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


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


Eric, if I understand you correctly, you're saying that the manner in
which trust is bestowed in keys should not be generalized.  Is this
correct?  I don't have a problem with that, and wasn't terribly interested
in defining trust parameters.  I do want to finish this in the next 4 to 6
weeks, after all.

However, that's not exactly the problem I'm trying to solve;  The phrase
"key management" is likely too vague or perhaps has specific connotations
that I'm unaware of, such that I'm using it wrongly.  I was never strong
on jargon, and "key management" is the phrase that came closest to an
expression of the problem I'm trying to solve.

The problem is this: You have a bitstream and you want to perform
a cryptographic function on it.  Therefore, you need a key.  For RSA
functions, I know of two different ways that keys are distributed:
PGP and X.509.  My intent is to support PGP keyrings and PEM-style
keyrings (I am not yet familiar with the latter)... having a way to
place keys into their proper keyrings would be nice, too, but there's
no way I'm going to worry about that in the first rev.  Would I be
understanding you correctly if I characterized your advice as being
to not plan to implement that at all?

There are two ways that I could approach handling keys in the code:

	1- Have a general RSA key format.  The would include parameters
	that are defined in either PGP and X.509 keys and would allow
	the code to hand back warnings such as "this key is not trusted
	by you" and "this key has expired."  This seems to be what you're
	advising against... 

	2- Have only a bare-bones key format that includes only the
	information necessary for crypto functions.  This is the way
	I'm leaning for several reasons, not the least of which is
	what you cite.

In either case, there must be an import function, extracting the key from
the appropriate keyrings or otherwise supplying the key.  Including functions
that extract keys from the appropriate PGP/PEM keyrings would be a Good
Thing and is right now The Plan: one can hardly expect the code to get
used if it needs Yet Another (undefined) Key Distribution method.

My X.509 vs PGP key question boils down to this: is it reasonable to try to
convert keys of one sort into keys of the other sort, providing the
functionality of converting a key obtained through an X.509 certificate
into a PGP-key?  Converting the other seems like a less desirable thing
to do, so I'm not really thinking about that problem.

I should note that in all cases in HCT where something is parameterized,
the caller can supply a callback function that matches the defined
interface and expect to win.  Thus, it's already supported (in the
general interface and soon the key handling) that a user could say
(in pseudo C code, missing parameters):

	erics_key_stub_fn(char *id, struct keytype *key, ...);

	...
	struct keytype *thiskey;
	thiskey = keyinit( KEYTYPE_RSA, (void *) erics_key_stub_fn, ...);
	if (!(get_key( thiskey, "eric@remailer.net",...))) {
          /* ... Do the right thing, etc. */
        }

Are we on a similar wavelength here, or am I totally missing the point?
The input is appreciated.

	-- Todd
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzqEYCoZzwIn1bdtAQHUcwF/QO2s178YMsxdSWQj6UDDErCDRv6+gaB5
CJnEyrRPwpS8jqRLOSDQmyjHDvOJbJS2
=xm8Q
-----END PGP SIGNATURE-----