[IETF-PKIX] Cryptographic binding of certificates to signatures

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

(My apologies if a copy of this message with a different
subject is received. Our e-mail, and apparently that of
some other people, has been acting very strangely recently.
I don't know what is going on, but some incoming
messages are showing up a week late, and some
messages on other lists apparently aren't getting through at all.)


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?

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.

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

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.

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.

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

Whaddaya think about the basic concept?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.,
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

--------

>>> "David P. Kemp" <dpkemp@MISSI.NCSC.MIL> 3/5/98 13:03:16 >>>
> 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