I've noticed that RecipientInfo identifies a key with a CHOICE between
IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows
IssuerAndSerialNumber. Presumably whatever reason requires the SKI in the
RecipientInfo should also require it in the SignerInfo, could these be merged
to create a unified identifier type (ie they both use a RecipientInfo-style
CHOICE)?
The addition of SubjectKeyIdentifier to SignerInfo was considered. Many
developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
was more important that the shorter certificate reference.
The reason I brought it up was because of the inconsistency in identifying
certs which currently exists - depending on whether you're signing or
encrypting, you end up with different identifiers, and if there was some
overwhelming reason which made SKI's necessary for RecipientInfo then I
would have assumed that the same argument applied for SignerInfo.
In terms of the backwards-compatibility argument, it's already present
in RecipientInfo and doesn't seem to have caused any trouble, so if it works
fine for RecipientInfo why shouldn't it work for SignerInfo? It can be
handled in exactly the same manner as the RecipientInfo... any argument
against having it in SignerInfo would also count against its use in
RecipientInfo, but it's being used in RI already, so I'm not sure why it
can't also be used in SI.
(I'm not just arguing this point to be difficult, there's a genuine use
for SKI's when used with things like PGP keys, at the moment this works
just fine for RI's but doesn't work at all for SI's if they don't allow
the same type of key identification as RI's).
Peter.