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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

David,

You posted a VERY important E-mail last week and I am bringing my
support to it.

> 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.

True.

> 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.

I believe that at the time, PKCS#7 was written, the authors had not
non-repudiation in mind, but simply using a digital signature for
authenticating a message in real time. For that purpose, the format was
fine.

> 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.

As the CMS standard is being rewritten in the smime working group,
(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
a member of the PKIX working group I think it is the perfect time to
suggest to make changes. What do you think Russ ?

> 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.)

Yes. Without breaking compatibility we could also support a SEQUENCE OF
issuerAndSerialNumber. The simple change that is needed is to add this
attribute in the section 11 (Useful Attributes) from the CMS document.
In addition we should mandate the support of such an attribute, if the
signed data is to be used in a non-repudiation process.

> 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.)

Unfortunately I am not yet on this mailing list, so why I respond here.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas@bull.net
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21