Jeff, I think I understand your point of view now, although I may not agree
with it fully.
In RIPEM and the other implementations I'm aware of, the user's
(current) public and private keys are loaded into memory before
receiving an encrypted message. In this case, recognizing the public
key in a Recipient-Key-Asymmetric is trivial.
In the case of an older public key, or one from another role, consider
an encrypted message with 10 recipients. If one of these is meant for
an old key or a role which you haven't announced to your application
(and loaded the key into memory), how will you find out? You will
just get an error message saying "This is not encrypted for you." If
anything more user friendly is going to happen, there must be a list
somewhere of alternate acccessible keys (moreof that "local matter"
stuff) which your application can check, and this list will in some
way reference your public key.
At least with the benefit of 20/20 hindsight, I would have loaded the current
and past _certificates_ I might expect to process, along with the corresponding
private keys (assuming they are stored in a smart card or smart disk.) If I
receive a message that is encrypted with a certificate containing my issuer and
serial number, determining which certificate to use and therefore which private
key is, as you say, a trivial matter.
Moreover, an application with smart certificate chain checking code
*will not accept an issuer/serial at face value.* The reason is this:
I may have gotten my perfectly good public key re-certified by my
issuer because the first certificate expired after a year. If you
send me an encrypted message and indicate my old issuer/serial in the
recipient ID, my application might look up the certificate and say
that the key is expired. But it's not! The same problem occurs if you
try to verify a signed message from me that I made last year. Your
application may say the public key has expired. (This is a good
litmus test for unsophisticated crypto software.) A smart application
would care instead about the *key*, and would look at the certificate
information in the message only so long as necessary to find the
latest and most trustworthy certification information - i.e., my
currently valid certificate, *not* the one referenced in the message.
You are pointing out the fact that we still don't have a good (written down)
model of what to do about expired certificates, nor how to manage the process
during the transition period when certificates/keys are changing (or for
archived messages).
I do not "grok" keys expiring. Public keys live forever, enshrined in the data
archives whether the owner wants them to or not. Private keys may be destroyed,
but the association between a private key and a public key endures forever. It
is the BINDING of a key to a claimed identity that may expire, as I'm sure you
understand but I want to reinforce. It is precisely BECAUSE some
implementations might (sloppily, IMHO) allow a user to reuse a key across
different roles, or across certificate expirations, that I think that it is the
certificate, not the key, that should be checked. Otherwise, I believe that
there may be serious issues in the area of nonrepudiation. including which CRL
to believe and/or require.
I mention these things to show the method behind my madness in
preferring public keys over issuer/serials.
On a madness scale of 1 to 10, I would certainly put you lower down than some
others I can think of but haven't yet persuaded. :-)
Your specific question is
about whether still using the issuer/serial in the recipient ID could
work, especially if your private key is resident on a smart card.
This confuses me a little. If you are trying to find one of your
private keys to decrypt the message, it seems more likely that you
would be able to ask a smart card to list the public keys stored on
the device, than to list the issuer/serial numbers. Such a device may
not even track such certification information but only hold keys and
perform crypto operations. How was it that the smart card was an
argument in favor of using issuer/serial as the recipient ID?
Hmm. I'll have to think about that, and maybe even conduct a reality check by
checking a few such cards to see what kind of information is available.
In any case, it is comforting to know that you only use a bare key in the
particular case of the recipient_ID. And based on what you have said, although
you have a preference, I assume that the world would not stop if you decided to
adopt the issuer/serial convention.
Changes to RIPEM aren't within the scope of this list in any case, I assume.
And since RIPEM was (at least initially) intended to be sort of a "PEM-Lite",
some of the simplifying assumptions that you made such as having all fo the
keys in memory are not unrealistic. I was merely trying to see if we could
economize on some of the mechanisms, and gradually force PEM, RIPEM, PEM/MIME,
and eventually PGP (gasp) to use a consistent (and small) set of common
operations.
Aren't standards wonderful? Especially if everybody has their own??
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820