Re: [IETF-PKIX] Cryptographic binding of certificates to signatures

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Bob,
  I'm sorry not to have replied sooner.  The approach sounds promising,
but I haven't thought about the details enough to comment substantially.
Offhand, I don't see a problem with defining new signature algorithms,
with new OIDs, which compute signatures over the concatenation of
the ToBeSigned message digest and the ancillary information.

I do see a problem with including salt (randomized padding) in the
signature computation - it would have to be transmitted as part of the
signature value, which would expand the size of the signature: DSA
signatures would become something like:

  DSASignatureValue ::= SEQUENCE {
      r      INTEGER,
      s      INTEGER,
      salt   OCTET STRING }

Can't this "problem", if it exists, be addressed at the application
layer?

Dave Kemp



> From: Bob Jueneman <BJUENEMAN@NOVELL.COM>
>
> 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.
>
>   [...]
>
> 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)).