Jeff:
.... 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.
Agreed. This is why I have argued in support of the arbitrary key selector
rather than just the issuer/serial-number pair. Nevertheless, it is very
common
for there to be just one certificate for a key, in which case it may simplify
the implementation to use the issuer/serial-number pair to identify both key
and
certificate, hence I think it appropriate to have that as an option too.
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.
You are now getting close to satisfying my residual concern, namely how to
optionally carry originator certificate(s) with the message. I am afraid my
reading of the Draft did not give me the clear impression that
application/pemkey-data was intended to be used that way (although it does not
preclude that) - the document seems much more to suggest that
application/pemkey-data is a response to application/pemkey-request. If indeed
this is the intent, then I would request, at least, editorial changes which
state that application/pemkey-data can be used that way plus include an
example.
In fact, I would suggest it go further - state that use of an attached
application/pemkey-data is a "standard procedure" when originator
certificate(s)
is/are to be conveyed with a message. Without such statement, it is unlikely
interoperable implementations will result.
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..."
But this argument can only be sustained if it is made mandatory to convey
certificate(s) in an attached application/pemkey-data. I think that would be
going too far - it seems more reasonable to make it optional to carry
certificate(s) that way. Implementations should still be able to work properly
if the certificate(s) are omitted.
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.
You have presented a sound argument for using key-selectors rather than just
one
certificate or even an issuer/serial-no pair. However, this is not a case for
restricting the form of key-selectors. All my earlier reasons for favoring
arbitrary key selectors stand.
I would appreciate views of the authors on the above-discussed style of usage
of
application/pemkey-data. If they agree with that style of usage, would the
document changes I suggested be acceptable?
Warwick