[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: public key algorithm naming

This message probably isn't as easy to read as it could be, but
try to bear with me. If it's not clear in some point, please let
me know and I'll try to explain.

Carl Ellison writes:
> Eric Rescorla of Terisa made a strong request at the last SPKI WG meeting 
> (in DC) for public keys to carry just key parameters and raw algorithm 
> names, not the three items we have lumped together:  PKalgorithm-hash-packing.
> Eric's view received a certain amount of support at the meeting.
> 
> We all agree that all three need to be specified and anchored by the time a 
> signature is checked.  This is required for security.
> 
> Eric preferred to have them anchored as late as possible.
> 
> On the other side of this, Ron Rivest far prefers to declare them up front.
That wasn't quite what I understood Ron's position to be. Maybe we could
get Ron to take a crack at explaining himself.

> I prefer (I).
> 
> 1)	Under (I), we have the same structure no matter which of these two
> 	PK algorithms we use -- and no matter which new ones we decide to 
> 	support (e.g., EC).  The others require the code to grab some of this
> 	necessary information from different places.
> 
> 2)	Under (II) and (III), we have to form a hash for the signature block
> 	which is not the hash of the signed object (certificate body).  Under
> 	(I), the hash of the certificate body goes directly into the signature.
> 	If we form another layer of hash, we have the choice of building a new
> 	S-expression composed of the old body and the new information, and then
> 	hashing that (something I object to, from painful earlier experience
> 	with X.509) -- or of building a new structure that holds hashes of
> 	the relevant information pieces and hashing that.
> 
> 3)	Under (III), we might wait until after we have done the RSA operation
> 	to verify the signature before we can start hashing the body to be hashed
> 	because only then do we know what hash algorithm to use.  I prefer to
> 	do hashing up front, when I receive the certificate body, rather than
> 	wait until I receive a signature on it.  [This is a much more minor
> 	point than (1) and (2).]
> 
> 
> - - From the point of view of code simplicity, not to mention specification 
> simplicity, I believe (I) wins on all counts.
> 
> Discussion?
There are two conditions that need to be fulfilled:
1. A security condition: It must not be possible to substitute
the digest algorithm for hashed messages. 

2. An interoperability condition: It must be possible to determine 
which digest algorithm/packing was used in order to verify the
signature.

These conditions can be (and probably should be) fulfilled separately.

The security condition for DSA is fulfilled by requiring that 
it be used with SHA-1. This can be done either by naming 
(i.e. DSA-SHA1) or simply (my preference) by fiat (i.e. call it
DSS and describe it as DSA with SHA-1).
The security condition for RSA is fulfilled by incorporating the
digest identifier in the signature, precisely as is done with PKCS-1.
Note that the digest identifier is NOT included in the digest,
since this isn't secure. Rather, it's signed along with the digest.
This is possible because RSA moduli are longer than any normal digest.

The interoperability condition is fulfilled by having the signature
include the name of the digest (and if necessary the padding) as
part of the structure. I'm not an S-expression wizard, so I hope
you'll forgive the probably clumsy expression here:

signature :: "(" "signature" <signature-algorithm> <signature-data> ")"

signature-algorithm :: "(" "signature-algorithm" <algorithm-name>
			   [<digest-algorithm-name> <padding-type>?]? ")"

  (This probably isn't right. The idea is that if the digest name shows
   up the padding type must show up too)

The verification algorithm goes like this:
Compute the hash based on the digest algorithm.
Verify the signature.
Check that the correct digest algorithm was used, if necessary.

I agree that this is slightly more complicated, but I think that
this complication is worthwhile, because it adds substantial flexibility.
There are a number of security protocols which offer algorithm choice
for digest algorithms. Having the digest algorithm bound to the 
key like you suggest has a number of unpleasant side effects:

1. It leads to proliferation of keys which only differ in
digest algorithm, which confuses users.
2. It makes the interaction of algorithm choice with key choice
more complicated, which confuses protocol engine authors.
	I.e. before you could let the user choose a key, then
	choose a digest algorithm and be done with it. Now you
	select only the keys for which you can negotiate digest
	algorithms, let the user choose one, then use that to pick
	a digest algorithm.
3. Worse yet, it requires SPKI to be cognizant of all sorts of
wacky signing techniques--and to provide identifiers for those
techniques even when they will never be used in SPKI itself,
but only in other protocols.
	Consider, for instance, SSL, where signatures are computed over
	two concatenated (keyed) digests. We'll have to come up with
	a name for that. For that matter, we'll need a new name for
	ISAKMP since they do something kind of different. Yuck.

I agree that simplicity is a virtue, but so is flexibility. And the
simplicity you want to achieve in this code comes at the cost of 
complexity in other code.

-Ekr

P.S. As a side note, signature data probably can't just be a 
byte string, since some signature schemes generate something
more complicated. (I.e. DSA generates two numbers, r and s)
Follow-Ups: