It was suggested that I could use one of the two <id> forms that
don't require a <keyid>, which are <id-publickey> and
<id-issuer>. But since the TIS PCA has no issuer, I can't use
<id-issuer>. This will be the same problem for any entity at
the "top" of a chain.
I bring up this example to highlight the implementation difficulties
of keeping track of an arbitrary keyid.
I would argue that the "top" is always a special case, regardless of the
mechanism to handle it. As Mark Feldman pointed out, we handle it by
identifying "tops" with self-signed certificates. Interestingly, doing
so makes most of the special case processing go away.
I would also disagree with your assertion of the implementation
difficulties of keeping track of an arbitrary keyid. The database
mechanism we're using now uses the public key as the unique index
element for each "user record", although each user record may be looked
up via any data in the record. One of the data values in the record is
the "identifiers", which are the name form/key identifier pairs. More
details on request.
Nonetheless, we do need a way
to distinguish among the public keys that an entity may use. The
previous draft, draft-ietf-pem-mime-05.txt, used fields like this:
<id-email> ::= "EN" "," <atstring>
"," <hashalgid> "," <hashpublickey>
<id-string> ::= "STR" "," <string>
"," <hashalgid> "," <hashpublickey>
<id-dname> ::= "DN" "," <dname>
"," <hashalgid> "," <hashpublickey>
This is basically what we have in the current draft except a public
key hash was used instead of the present keyid. It had the advantage
that the key identifier was not arbitrary and could be derived
directly from the public key. There was no need for a database to
seperately store the keyid or for a user to have to convey it.
However, this scheme was abandoned because not all applications would
be willing to implement the hash algorithm that a sender might use
such as MD5 or SHA.
Your last statement is false. The reasons for moving away from hashing
the public key was because there was no motivation for the additional
complexity. First, applying the hash meant you had to indicate which
hash algorithm is to be used. This suggests there will be more than one
(perhaps not initially but I can imagine at least SHA and MD5 wanting to
exist). As soon as there's more than one you have to remember which one
is preferred. This is tantamount to remembering the key identifier in
the first place.
Second, there are communities using other mechanisms inconsistent with
hashing anything. In particular, PGP simply uses arbitrary hex values
assigned by users.
We believed the best solution was to specify the property required of
the key identifier (unique per public key per user) and specify a syntax
that would allow implementations to use what is most convenient for
them.
Jim
bin44jwApKxcC.bin
Description: application/signature