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

Re: public key algorithm naming

fredette@theory.lcs.mit.edu (Matt Fredette) writes:
> > Message-Id: <3.0.3.32.19980314020906.00a55100@cybercash.com>
> In a conversation Carl and I had at IETF, he remarked that he had convinced
> Eric Rescorla that the signature encoding algorithm does need to be part
> of a key's name.  Here's the argument: if encoding algorithm could be 
> specified on a signature-by-signature basis, I might construct a new, 
> not-unreasonable encoding algorithm that, with certs of my choosing, lets
> me reuse your RSA-PKCS1 signatures as signatures using my marvelous new
> encoding.
Matt, I'm having a really hard time reading your message to see
what it is you currently believe. Is the above text a quote or
your current position?

In any case, I do NOT agree that the signature encoding algorithm
needs to be part of a key's name. PKCS-1 itself prevents the
substitution attack, as I believe I indicated at IETF.

> To try to summarize my position:
> 
> -  I'd like to leave this unchanged from the current draft, and cement it:
> 
>    <pub-sig-alg-id>:: "rsa-pkcs1-md5" | "rsa-pkcs1-sha1" | "rsa-pkcs1" |
>    "dsa-sha1" | <uri> ;
> 
>     If someone using RSA wants to specify a hash that they'll stick with
>     forever, let them, but remind them that they can't change it - that
>     the hash name factors into hashes of the key and key equality tests,
>     and forces signatures to be made using that hash.  If someone doesn't 
>     want to specify their hash, also let them.
To be honest, this seems like a bad plan. Better to come down on one
side or the other than to allow both.

> -  For Section 3.8.3.1 <sig-val>, I'd like:
> 
>    <sig-val> depends on the <pub-sig-alg-id> -- the algorithm listed in
>    the public key.
> 
>    For rsa-pkcs1-md5 and rsa-pkcs1-sha1, <sig-val> is a <byte-string> --
>    the value of the RSA signature operation using the specified hash function. 
>
>    For rsa-pkcs1, <sig-val> is a <byte-string> -- the value of the RSA 
>    signature operation, using a hash function that was chosen at signing 
>    time.
This doesn't seem very convenient. Having the digest algorithm name 
available separately is an excellent idea from an implementation
perspective. In particular, some crypto APIs do not actually let you
get the text that was signed, but rather require you to input the
digest, with an API like so:

	VerifySignature(
          ALGORITHM_ID		 digestID,
          char			*digest,
          int			 digestLen,
	  char			*signature,
	  int			 signatureLen
        )

Such APIs cannot be used without external information about the digest
algorithm. 

There's another quibble I have with all of this: PKCS-1 is both
a message padding AND a format for RSA key encoding. But PKIX does
NOT use the PKCS-1 RSA key encoding. Consequently, having a 
key tagged as rsa-pkcs1 seems kind of confusing.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."
Follow-Ups: References: