[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
public key algorithm naming
-----BEGIN PGP SIGNED MESSAGE-----
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.
Discussion?
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQCVAwUBNQgOkBN3Wx8QwqUtAQGBrgQAkTcmKn7Ri/6BCZxKOmCnAA9SBlCWBd8I
sjMfpvTxJkkRaol+rvm7QdaBSTkVguSVwoeRrsBCopigI4W5uAgPdd+FN9jgjEYl
ZnQz3SIn5c64M1swZmF11MRB1LWrALtCqL5fNtpJQBtE95LPXUufSTRph5zwPpzh
CFICyTaGVwI=
=wrUU
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 |
+------------------------------------------------------------------+