Russ Housley <housley(_at_)spyrus(_dot_)com> wrote:
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.
Ah, finally an explanation for the decision. Thanks.
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.
The reason I brought the issue up is that the lack of a key identifier in
SignerInfo makes CMS impossible to use with SPKI and PGP. There was a debate
in two other lists a while back (OpenPGP and something else) in which someone
commented on PGP <-> CMS compatibility, and I pointed out that it would
*almost* work, but required the inclusion of a key identifier. The same goes
for SPKI, where the only way to identify a key is with the hash-of-key/key
identifier. In neither of these cases is it possible to use the
issuerAndSerialNumber to specify the signers key, which means CMS is
restricted to only one of the three IETF-standardised certificate management
methods. The addition of a key identifier would immediately extend this to
both SPKI and PGP, since both already use an SHA-1 hash of the key as their
identifier. I think that extending the identifier in this way would be a
significant win in terms of extending the usability of CMS to all three of the
IETF certificate types.
Might I suggest the following text, based on the existing
'rid RecipientIdentifier' descriptive text and Russ' comments:
-- Snip --
sid specifies the signer's certificate or key that was used by the sender to
sign the content. The SignerIdentifier provides two alternatives for
specifying the signer's certificate, and thereby the signer's public key. The
issuerAndSerialNumber alternative identifies the signer's certificate by the
issuer's distinguished name and the certificate serial number; the
subjectKeyIdentifier identifies the signer's certificate by the X.509
subjectKeyIdentifier extension value. When used with X.509 certificates the
signer MUST use the issuerAndSerialNumber form, since the key identifier only
identifies the signing key and not the exact signing certificate, allowing an
attacker to substitute other certificates which contain the same key. When
used with non-X.509 keys such as those used in SPKI or OpenPGP, the signer MAY
use the key identifier form.
-- Snip --
This should keep both sides happy, the people grumbling about backwards
compatibility can just ignore SPKI and PGP keys so there's no change required
for their code, and the SPKI and PGP crowd are given a way to integrate their
keys into CMS. Since the two identifiers are now identical for RecipientInfo
and SignerInfo, they could probably be merged into a unified type, keeping the
text for signing as a special case for identifiers used for signing only.
This has a slight problem in that you don't know which key store to search to
find a key corresponding to a given identifier. Admittedly the chances of
someone getting the same public key certified for X.509 and SPKI are pretty
remote, but a slight improvement might be to indicate the type of identifier
so that the recipient/relying party knew where to get their keys from:
WhateverIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
keyIdentifier [0] SubjectKeyIdentifier, -- SHA-1 hash
spkiIdentifier [1] SPKIGloballyUniqueID, -- SHA-1 hash for SPKI key
pgpIdentifier [2] PGPKeyIdentifier, -- SHA-1 hash for PGP key
otherIdentifier [3] OtherIdentifier -- For future expansion or
other key mgt.mechanisms
}
OtherIdentifier ::= SEQUENCE {
otherID OBJECT IDENTIFIER,
otherValue ANY DEFINED BY otherID
}
This is what was planned in PKCS7v2, at least in the last draft I saw. If the
S/MIME folks really are that upset about this, they can just require that the
non-X.509 identifiers not be used, although it'd be a significant olive branch
for the other factions if you could use any type of key.
Peter.