At 03:25 PM 11/28/98 +0000, Peter Gutmann wrote:
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.
No. In general S/MIME usage, SignedData will have one SignerInfo. With a
single signer, there is not a great motivation to reduce the size of the
certificate reference.
On the other hand, the number of recipients contained in an EnvelopedData
may be quite significant. For this reason, RecipientInfo supports the
shorter form of certificate reference.
Further, some people argued that the key is not the only thing that is
important in verifying a signature. Other fields in the certificate, like
policy, are important too. If a signer has the same public key in two
certificates, then an attacker can swap the certificate carried in the
certificates field. Since PKIX recommends a form of key identifier based
on hashing the public key, then the relying pary will probably not be able
to determine that the certificates were swapped. Since the issuer / serial
pair specifies a certificate, not just a public key, it seems to be the
prefered method for signatures.
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).
Agreed, it could be added without breaking backward compatibility. Support
for key identifiers could be added to SignerInfo, but as stated above,
there is less motivation to do so.
Again, signatures should reference a particular certificate, not just a
public key.
Russ