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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

Bob, I am sorry and I should have responded to your message as well.
When I read your message (I did see it), I was not very enthusiastic
with your first proposal (i.e. modifying the SIGNED MACRO) and ... did
not go until the end, so I missed the second proposal which is much
better.

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

You mean issuer name and serial number (not issuer serial number).

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

Don't put too much !

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

Hereafter is your original message again :

> David,
>
> If we were able to somehow add cryptographic binding of
> the digital signature to the specific certificate that is s
> supposed to be used to validate it, virtually all of my objections
> to issuing more than one certificate per key would disappear,
> and we would be left with some of the positive virtues of that
> approach that others have mentioned.
>
> However, I do NOT think that we should insist that each and
> every protocol reinvent the wheel. Some will do it wrong (as per
> your examples), and some just won't do it at all.
>
> Unfortunately, the SIGNED macro doesn't include a version
> indicator (will we _never_ learn?), so we can't do the version 3
> trick that we pulled when we found that the X.509 certificate
> wasn't adequate for our new extended purpose.
>
> However, I think there is a way out, although from a purist
> architectural standpoint it is an ugly hack. But hey, MISSI did
> it, and what's good enough for the US Government ought to be
> good enough for the rest of us, right?

Let us skip this and go directly to the second proposal.

> What I'm proposing is that we define a new series of digital signature
> algorithm OIDs, which would include the additional information that
> is needed as part of the COMPONENTS.
>
> We can debate the precise information that we might like to include later,
> along with the optimum syntax, but this is the approach that as I
> recall MISSI took to include clearance information and other parameters
> that they had no place to put in the old V1 certificate format. Like I said,
> an ugly, but noble hack.
>
> One potential problem is that although currently in-vogue RSA and
> DSA key lengths (1024 and 2048 bits) would probably be long enough
> to directly include most of what we might like, the 512 bit lengths allowed
> by US export (and some import) regulations might be pretty tight, and
> would be extremely tight for elliptic curves.
>
> One approach to solving this problem would be to use two message digests,
> one for the ToBeSigned, and the other for the ancillary signature data (someone
> has to think of a snappy attribute name ¯ I refuse to be blamed for
> "ancillarySignatureData"), and then include both message digests
> within the signature.  This would work for algorithms of up to 320 bits
> in length, which might still be tight for some elliptic curve algorithms.

Here starts the second proposal.

> The other approach, which could be extended to arbitrarily long
> information, would be to effectively append the existing ToBeSigned
> information (normally a message digest) to the ancillary information, and
> then compute a super message digest over the entire collection. That
> super message digest, plus any additional randomized padding (we
> ought to fix that problem while we are at it) would then be the input
> to the actual signing operation. This would support signature algorithms
> and key lengths which only allow as little as 160 bits of input (or even
> 128 bits, for MD5)).

I agree in principle with the approach. We need to consider two one-way
functions.

> The second approach is obviously superior to the first, assuming
> that the time for a second hash is considered negligible. But can
> anyone think of an even better method?
>
> The benefit of this scheme is that by simply implementing one
> or more new enhanced signature algorithms (e.g., "RSA with
> SHA-1 and ancillary data") within the underlying toolkits,
> virtually all applications would benefit, with virtually no effort at all.

I see it slightly differently. If I want to sign a message with a length
of 1 Mo together with ancillary information, I would like to sign the
message digest of the message instead of the message.

Considering that we are not going to optimize the scheme for messages
smaller than 160 bits, we could always consider to sign the hash of the
message, instead of the message itself. Thus we would sign what is
sometimes called the "imprint" of the message. What is nice is that the
imprint of a message is a characteristic of the message that can be
computed independently of the context of the signature. It can be
generated or check in advance or in parallel. The last step would then
be to compute a hash over that message imprint and the ancillary
information. If there no ancillary information this appears useless, but
there will be !

I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary". To make it clear, instead of "RSA
with SHA-1 and ancillary data" I would prefer to keep "RSA with SHA-1"
but sign an explicit message digest plus ancillary data. When looking
again to the E-mail I sent yesterday, although the addition of
authenticated attributes solves the problem from a security point of
view, it suffers from the performance mentionned above. If you want to
take a look at the CMS specification, it is available at :
ftp://ietf.org/internet-drafts/draft-ietf-smime-cms-03.txt

> And if we do it right, we might even be able to achieve some degree of
> backward compatibility by some sort of slight of hand involving
> mapping the algorithm OIDs to existing algorithms
> in such a way as to ignore the added information if the code doesn't yet
> support it. Maybe some ASN.1 genius can think of a slick trick.

I would prefer a solution without the help of an ASN.1 genius so that
everyone can understand it.  :-)

> Let me let this sink in before I start talking about all of the stuff I
> would like to see included. Hopefully this time we would do it right,
> probably by defining the information to be included in ASN.1 with
> strong typing, so that we additional information is proposed to be
> added it will be simple to do. But that is tomorrow's homework
> assignment.
>
> At a minimum, however, it would have to include some form of
> unique identification of the certificate to be used to validate the
> signature, either issuerName and serial,

This is indeed the minimum, although a SEQUENCE would be more
appropriate and solve the problem of unique names.

> authorityKeyId, or at
> the very least a hash of the certificate contents (although that
> wold cause some problems of circular definition if used within
> the certificate itself.)  Certainly a URL or some other kind of hint
> as to where to actually find the certificate would be a nice touch,
> but we can discuss that independently of the primary issue.

Don't put too much in the same boat ...  :-)

> Whaddaya think about the basic concept?
> Bob

You are certainly on the right track, but do not overload the boat ...

Denis

P.S. My original E-mail follows.


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

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