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

[Russ Housley <housley@xxxxxxxxxx>]

Denis:

I suggest that the ietf-smime@imc.org lists is the place for this
discussion.  PLease raise this issue there, and we can discuss it ...

Russ


At 03:11 PM 3/9/98 -0800, Denis Pinkas wrote:
>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
>