First, I apologize for taking so long to respond to your question to
the "draft authors". I've been the only one of the authors here at
TIS for the last week, so the fault is all mine.
You say:
Can the draft authors speak to this point? Is an implementation
required to process name forms with a keyid in order to be compliant?
Yes, an implementation must be able to process name forms with a keyid
in order to be compliant. To make it otherwise would raise the
possibility of non-interoperability -- balkanized groups of users
who use different implementations and can communicate within the group
but not with users of other implementations.
And, now that you've mentioned it, I suppose we must explicitly discuss
compliance requirements in the text.
If so, what exactly is the recommended database mechanism which will
let me "index by the various name forms" and how is it supposed to be
secured/authenticated?
The database mechanism is a local matter. We do not recommend any
particular database mechanism. If you are looking for non-binding
suggestions, I can tell you what TIS is doing.
We have eliminated the certificate orientation for the database as
well as the hashing and lookups. We are making the public key itself
the fundamental orientation of the database. We are also going to a
flat ascii file with no hierarchy. Looking for a match to a received
name form will be done with a sequential search. We believe that the
number of certificates we were dealing with made the hashing, opening
and closing the hash file, etc., actually more expensive than just
reading the ascii file. There's a point where the economies of scale
come into play and we don't think we'll reach it for an appreciable
time.
If by "secured/authenticated" you mean how does one trust the binding
of a name form to an identity and keep the binding's integrity
protected, then you have to realize that these new name forms do not
have the trust designed in to them that is designed into the
certificate hierarchy. The price you pay for a more user friendly
name is no built-in trust model. Which is not to say that you
couldn't create a trust model, e.g., by signing key-data responses
(and whatever other information, such as validity periods, you would
like to have in your trust model). You could even establish a
hierarchy of signed responses. If you go whole-hog, you could
re-invent the present PEM certificate hierarchy.
I summary: If my application doesn't implement keyid and is still
considered MIME/PEM compliant, I will use the public key and be
merrily on my way. If it is required, I propose using the checksum
which is non arbitrary and does not need a seperate mechanism for
keeping track of it.
It is perfectly OK for you to use the public key for the keyids that
you generate yourself. It is also perfectly OK for you to use the
checksum to generate keyids. Your point is that you can generate the
keyid from the public key each time it is needed rather than store it.
So this works fine when you are generating the header fields. But it
only works when interpreting received headers if the checksum is
mandated for everyone as the keyid generation process. This may not
be palatable for everyone (note the requirement on PGP keyids that
they be either 6 or 8 characters long; a requirement chosen so as to
match the present PGP spec).
Problems with the keyid generation aside, you will always have to deal
with arbitrary values -- the email name, arbitrary string, and PGP
name forms are all arbitrary. As Mark pointed out, you will still
have to index by, store and keep track of these arbitrary values. I
do not understand why an arbitrary value for the keyid is more of a
problem.
Incidentally, it is perhaps interesting to some to note that if
someone sends you a message with a PGP identifier (containing a keyid
chosen for the purpose of hiding the public key) in it, there is
nothing in the present spec to prevent you from responding with a PK
identifier and thus exposing the public key to the gaze of all and
sundry.
Jim Galvin should be back later this week and may chime in on his own.
--Sandy