One week ago I posted a note with the summary of the four outstanding
technical issues with respect to the two documents. I asserted a
working group position and asked for comments. Here is a summary of the
comments that resulted.
1. Suggestion to require key selector to be the public key
This is the only contentious issue. There are clearly individuals on
both sides of the issue. The two sides of the issue are as follows:
Represented by the authors (Steve Crocker, Ned Freed, Jim Galvin,
Sandy Murphy):
Allow the key selector to be an arbitrary value
Represented by Steve Dusse and Jeff Thomson:
Require the key selector to be the public key
Warwick Ford and Jeff Schiller has expressed explicit support for
allowing the key selector to be an arbitrary value.
Burt Kaliski proposed an alternate mechanism: include the hash of the
public key.
Several others have explicitly expressed no preference.
My interpretation of these facts is that the rough consensus of the
working group is to progress the document as specified.
Jim, I think I was one of the first to raise a question about what the intent
was behind the key selector field. Later, I went through a fairly lengthy
discussion of the problems that might be associated with some of the notions
involved in traffic analysis. In the absense of a reply from you as to
precsiely why a key selctor was required at all, I posted a note conjecturing
why you felt it was necessary, and only recently have you replied to any of
these concerns. As we are only now getting down to the real nub of the matter,
I think that you have significantly overstated the degree to which a concensus
exists. If you are going to summarize positions, you ought to at least include
all of those who have provided comments.
At this point in time, I would seriously dispute the "requirement" to hide
public keys to prevent traffic analysis. The difficulties in preventing traffic
analysis, setting up anonymous e-mail forwarders, etc., in order to accomplish
this "goal" are rather formidable, and unless a reasonably clear technical
solution to the general problem is seen, spending any time at all on this point
would be a serious mistake, IMHO.
Likewise, I believe that hiding the public keys to prevent or forestall
cryptanalysis is very likely to produce a false sense of security. Security via
obscurity generally fools only the participants.
Warwick has raised the valid point that it may very well be necessary to
distinguish between different keys over time, as a way of identifying which key
must be used by the recipient to decrypt a given message. In my previous
analysis, I somewhat casually suggested that all of the user's keys be tried
until the right one is found, but I agree that might not be too feasible if
messages are archived in encrypted form for many decades. But even accepting
this point, we have a perfectly good way of identifying the key -- by
identifying the certificate that contains it, i.e., by specifying the issuer
and serial number.
There could conceivably be a privacy issue involved in disclosing the issuer
name in a certificate. Perhaps I wouldn't want the fact that I am certified by
Pond-Scum Certificates, Inc. to be generally known (or the Mafia, or the CIA,
or the Republican/Democratic party, etc.) I haven't hear that particular point
argued, but I would be somewhat more sympathetic to it than to the traffic
analysis or cryptanalysis issues.
Although using a key selector consisting of a key digest would potentially be
helpful to the recipient in deciding which key to use to decrypt the message,
it is of more marginal use in determining whose certificate should be examined
in order to determine who signed the message originally. Other than the fact
that I may not know how to find the database of the issuer's certificates given
only the issuer's name, at least I have a clue as to where to look. If I don't
already have the certificate in hand from the originator and only have the key
digest, I haven't any idea where to look until a worldwide directory of keys
indexed by such digests comes into existance.
I guess that my overriding concern is that the hidden agenda behind the use of
a key selector as opposed to the certificate issuer name and serial number is
the desire to abandon the use of certificates entirely and simply embrace the
PGP direct trust model directly. If that really is the bottom-line issue, then
I am absolutely adamently opposed to approving the PEM/MIME spec as an Internet
standard, no matter how many potential users there might be, because of the
damage I think that would do to other potential users of a more far-reaching
national or international public key infrastructure.
However, if this is not the real rsason behind the proposed use of key
selectors, and if there are some really good reasons why the issuer/serial
approach won't suffice, then I would suggest the use of a key digest as Kalisky
and others have suggested. Rather than get trapped in the issue of whose
hashing algorithm, etc. to use, I would suggest simply using the last 128 bits
of the public key.
What I really don't understand is how the use of an e-mail address as a key
selector is helpful at all, since I may have many different keys/certificates
that I use for dfferent roles at the same e-mail address. Likewise, I don't
understand the intent behind specifying some completely arbitrary private name
string as a key selector. But I do understand that as the originator of a
message, if my recipient is going to insist on having those kinds of fields
filled in, it is that much more work for me to support on my end. I am also not
at all sure how a the potential recipient of a message I am supposed to convey
whcih key selector to use to the originator. Is this an out of band transfer,
or is this magically included in the certificate distribution process?
To answer Phil Smiley's question regarding the database used to maintain
certificates, and speaking only for my set of potential users, my PRIMARY
requirement is that a compatible database be used for such purposes, and I
fully intend and expect that to be X.500. We certainly cannot afford to support
one large database for our e-mail subscribers, and another for our AOCE users,
and another for our electronic forms users, EDI, etc., etc.
That doesn't mean that I am holding my breath for the NADF or the Internet or
anyone else to get their act together and establish the global hookup of X.500
directory servers that we have all imagined. That may or may not ever happen,
especialy if everyone expects such services to be free. But we can CERTAINLY
implement X.500 within our own corporate environment, and we can also file
e-mail names, certificates, etc. for outsiders within that database without
difficulty.
That doesn't mean that all of these applications have to speak X.500 DAP
directly, or even LDAP. A number of products have been developed that support a
fairly lightweight directory function, sufficient for the garden variety mail
packages, but don't require the direct use of X.500 at all. DEC's InfoBroker
product is one such example. I believe that Lotus Notes is moving the same
direction -- X.500 compatibility, if not direct interoperability. I would even
go so far as to suggest that an X.500 DUA is sufficiently complex that using a
intermediate server between a very lightweight DUA and the X.500 DSA would make
a lot of architectural sense. (The InfoBroker DUA client does include a API, by
the way, so it would be feasible to develop tailored applications on top of it.
I doubt that this is standardized, however, nor do I see any great requirement
for such API standardization at this time.)
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM