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

Re: public key algorithm naming


> At 01:34 PM 4/7/98 -0400, Matt Fredette wrote:
> >> 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:
> >
> >OK, I agree, and note that the algorithm used is still available separately
> >in the current grammar, in the <hash> in <signature>.
> 
> Hmmm.  Good catch.
> 
> That is all we need.  So, you've won me over and I'll vote for dropping
> the separate structure.
> 
> Does anyone want that separate structure for rsa-pkcs1 ?
> 
>  - Carl

Here's what I think this morning.  Again, from 
draft-ietf-spki-cert-structure-05.txt:

[snip]
3.8.3.1 <sig-val>

   <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.

   For dsa-sha1, <sig-val> is a <byte-string>, consisting of the
   concatenation of the values r and s (in that order) from the DSA.
   Each is of the length of the sub-prime, q.  We could split these
   values out in an S-expression, but at least one popular cryptographic
   package (BSAFE) assumes the two values are concatenated so that
   splitting and recombining would be extra work for the programmer.

   For rsa-pkcs1 (should that option be preferred by the working group
   over the specification of hash algorithm in the <pub-sig-alg-id>),
   <sig-val> would need to be:

   <sig-val>:: "(" "rsa-pkcs1-sig" <hash-alg-name> <byte-string> ")" ;
[snip]

For DSA, I'm in favor of having <sig-val> be an S-expression.  I don't
really like combining r and s into one bytestring because one crypto
implementation happens to accept them like that.  I like a little better
the motivation to try to keep <sig-val> always a bytestring, which lets 
the signature parsing code be simpler and ignorant of signature crypto 
algorithms' requirements, but in the end, trying to cram everything into
a bytestring results in a loss of clarity, I think.

So, if the DSA <sig-val> is an S-expression, then, that S-expression ought 
to be typed, in the spirit of language.  Something like:

(dsa-sig (r |123abc==|) (s |456def==|))

But if we're doing things that way for DSA, how about always making 
<sig-val> a typed S-expression?  For RSA, I'm thinking:

(rsa-sig |789f0e==|)

These types, "dsa-sig" and "rsa-sig" don't have to repeat any of the
encoding or hash names, since we've already seen that they are elsewhere.
They really just serve to type the values of a signature in that cryptosystem, 
which is (strongly in RSA, not-so-strongly in DSA) independent of the 
encoding and hash used.

Thoughts?

Matt

-- 
Matt Fredette
fredette@bbnplanet.com, fredette@mit.edu, fredette@theory.lcs.mit.edu
http://mit.edu/fredette/www
"The first time the Rolling Stones played, three people came."
Follow-Ups: References: