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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Denis, David was responding to my original post, which pointed out that
most of the difficulties we are having with mutliple certificates for the same
key is due to the fact that the certificate information is not cryptographically
bound to the message itself.

But did you see my follow up back to him?  I'm somewhat surprised that
no one responded to it. I suggested that instead of solving this problem
over and over again for each separate application we should fix
the root cause, the SIGNED macro itself.

I then proposed a way of doing that which would not invalidate existing
code, but would merely require the definition of a new set of signature
algorithm IDs, where the additional information we might like to cryptographically
bind would be snuck in as COMPONENTS of the signature. We might even
be able to find a way to make those additional components optional.

Such components should include the issuer and serial number at a minimum, and I
could come up with a list of additional information that could at least
be debated as to whether it was worthy of being included. Date/time would be
certainly be worth discussing, as would some indication of the platform on which
the signature was created (for audit purposes). If biometrics were used there
might be some additional information that would be useful, etc., etc., etc.

If you didn't see the original message, I'd be happy to send it again -- my
e-mail system was rather flakey that particular evening.

Bob


>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