The bare key you mention is only for the recipient of an ENCRYPTED
message. I would reiterate: there is no need for the recipient to be
indicated by a Warwick-style key selector or issuer/serial because
the recipient already knows their own public key. When I receive an
ENCRYPTED message, there is no need for me to look up my own key in a
database, or to verify a certificate from an issuer. When I was
participating in RFC 1421 development, if I had thought of just
putting the public key in a Recipient-Key-Asymmetric, instead of
using the recipient's issuer/serial in a Recipient-ID-Asymmetric,
even for strict 1422 hierarchies, I would have mentioned it then and
I think it would have been accepted. Doing this has nothing to do
specifically with direct trust. I think the recipient ID just ended
up that way out of aesthetic symmetry with the Originator-ID which is
an issuer/serial. (At least, that's what I was thinking.)
Let me probe this a little bit, in hopes of nudging the various derivitives
and
alternatives to PEM, together with PEM itself, a little closer together.
At first I would have tended to agree with you, but if you consider the
possibility of using multiple keys over time, your statement "there is no
need for me to look up my own key" may not be true. (I won't debate the
wisdom of periodically changing keys -- there are pros and cons that
depend on the users situtation.) And as was also pointed out, if your private
key is resident on a smart card, the user will have to maintain some type of a
local database just to specify which card corresponds to which public key.
Would it not have been possible for you to use the issuer/serial construct,
EVEN IN THE CASE OF A SELF-SIGNED CERTIFICATE, instead of
using the public key (or a digest) of the recipient's key? It seems to me
that this
might provide additional flexibility with respect to RFC 1421 compatibility,
with
no significant costs. Am I missing something?
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.
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.
I mention these things to show the method behind my madness in
preferring public keys over issuer/serials. 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?
- Jeff