The problem with certificate serial numbers is that the same key is often
certified several times (by the same or different CAs) so it is sometimes
useful
to recognize keys by key identifiers rather than certificate serial numbers.
For this reason, we are currently introducing key identifiers into X.509
certificates. I see MIME/PEM key selectors as fulfilling basically the same
role.
I succeeded in convincing Bob if the following, so I'll try my luck on
you. :-)
Suppose you have one key certified by different issuers A and B (or
one key used for different roles, as in Bob's case). And suppose you
sign a message and use key identifier 1, meaning "key signed by
issuer A". If I modify the message in transit to have key identifier
2, how could the recipient possibly know? It's the same public key,
so the signature will verify just as well. If one key is certified by
different issuers, or linked to different names (like residential name
and business name), or used for different roles, then there is no
*cryptographic* significance to giving the distinction in the
Originator-ID, since any of the others could be indicated and the
message will still verify.
Now, you may want to indicate the issuer because you know something
about the recipient: you know that the recipient will trust your key
if it is certified by issuer A, but not by issuer B. So if I change
the key selector in transit, when the recipient goes to look up your
certificate in the X.500 directory, the trusted one won't be found.
Fair enough. But in this case I would ask this: What if there are
multiple people who will want to verify this message, some who trust
issuer A and some who trust issuer B? To me, this highlights a
confusion about what the Originator-ID is for. People are trying to
use it to convey certification information, when all it should do is
convey cryptographic keying information.
The right answer, IMHO, is to satisfy the different recipients by
putting *both* your certificate from issuer A and from certificate B
in an attached application/pemkey-data body part. And indicate these
by putting your public key in the Originator-ID field. This is what
I'm after by suggesting we only use the public key as an ID: not to
leave the recipient high and dry trying to use this as a database
index, but simply a pointer to the application/pem-keydata body part
where the recipient can select among any certificate that looks
trustworthy. "Oh, here's a certificate from Issuer A who I
recognize..."
In summary, to me, the fact that one key may be certificate by
multiple issuers is one of the strongest arguments *in favor* of just
using the public key as the Originator-ID, because when you sign a
message, you never know which issuers each of the recipients will
trust and so you should not have to be forced to guess when you make
the Originator-ID (by putting in a key selector for only one of the
issuers). Instead, put any or all useful certs in the
application/pemkey-data that may be useful and let the recipient
decide.
In looking more into the potential deficiencies of MIME/PEM in the
infrastructure environment, the main one seems to be the inability to carry
an
originator's certificate in the message header (which 1421 supported). While
this is not essential (as the recipient can always do a Directory retrieval)
it
could represent a substantial performance issue. Most other application
protocols which support digital signatures include provision for carrying (at
least) one certificate along with the signature, so this looks like a
MIME/PEM
deficiency.
Reiterating: RFC 1421 forced you to choose only one of your
certificates to put in the Originator-Certificate field, even though
one of the recipients might want a different one (from a different
issuer). It is better to put the bag o' certificates in the
application/pemkey-data, letting the recipient's certificate chain
checking code decide which to use, and place the public key in the
Originator-ID as a pointer *only within the message* into the set of
certitifates.
- Jeff