Re: [IETF-PKIX] Multiple certificates for same key?

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Bob Jueneman <BJUENEMAN@NOVELL.COM>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp