Subject: Re: RecipientInfo vs SignerInfo key identification

From: [email-masked] (Peter Gutmann)
Date: Thu, 3 Dec 1998 16:05:48 (NZDT)

Russ Housley <[email-masked]> 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.