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

public key algorithm naming


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.

I would like to hear discussion on this.

Let me start.

There are different algorithms -- at least RSA and DSA.  DSA specifies all 
three options in the algorithm name.  RSA allows a choice (because the 
modulus is so big).

With RSA we have some choices.

I. We can specify all three in the algorithm name, as happens with DSA.

II. We can change the (signature ...) structure so that:
1.	it contains the hash and packing algorithm to be used
2.	a portion of that signature block would then need to be hashed along with 
the body being signed and that composite hash used in the signature.

III. RSA's modulus is so big, that we also have the choice of moving the hash 
algorithm name into the modulus, provided the packing algorithm specifies 
that we're doing that.

- --------

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.


 - Carl

Version: PGP for Personal Privacy 5.5.3


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |