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

Re: public key algorithm naming

-----BEGIN PGP SIGNED MESSAGE-----

At 04:41 PM 3/12/98 EST, Angelos D. Keromytis wrote:
>With signing keys, by placing a hash algorithm name in the key you're
>restricting yourself as to what parameters you'll use to sign. I find
>this unnecessary.

Strictly speaking this might be unnecessary.  IN that sense, I agree with 
you.  The side of me that wants to keep everything as open as possible for 
as long as possible (the mathematician?) likes that.

However, this openness is achieved at a price in code complexity and 
structure definition complexity.  Any option that defers binding this 
information until the signature must create a structure to hold that 
information.  For example,

(verification-params
  (hash-alg  sha1)
  (unpacking pkcs1)
  (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))
)
(do hash sha1)

would bind a hash algorithm and packing algorithm (actually, unpacking 
algorithm, if we want to be explicit (so I changed it above)) together with 
the hash of an object that doesn't include those (e.g., a cert body) and now 
this structure can be hashed and that hash can be put in the signature 
block.  That hash is sha1, of course.  Note that the body hash wasn't.  
That's a flaw.  Does the body hash need to be the same as the verification 
hash?

For DSA, of course, this structure wouldn't need to be there -- or would
need to be only

(verification-params
  (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))
)
(do hash sha1)

Of course, you could force that structure to be the same at all times by
including information not really needed.

(verification-params
  (pk-alg dsa)
  (hash-alg  sha1)
  (unpacking pkcs1)
  (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))
)
(do hash sha1)

or 

(verification-params
  (pk-alg rsa)
  (hash-alg  sha1)
  (unpacking pkcs1)
  (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))
)
(do hash sha1)

In that case, you probably need to do consistency checking.

- ----------

Anyway, as I said, this is a complication.  It is also a code complication, 
to me, that we would learn things about the verification procedure from 
different places for different PK algorithms.

In the interest of code and structure and explanation simplicity,
I prefer to keep all this info with the public key definition.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNQhcjBN3Wx8QwqUtAQH5JAP/S/tuJHWwRGb59LXHIN0aqdNjuhp2tlnu
BFdBGYDXRtFSEiDL2sXTkwugUNIGvp97Hc81MAWFQf+UWf2s9nuaI/e6per5tJfs
fFRrLuAETrZmYiDrSQrqxqF1BbikbPNy03jEjX0AwxsET1h0o7SCnvj8awyiEJZm
GOSWncap8V0=
=oPD3
-----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        |
+------------------------------------------------------------------+
Follow-Ups: References: