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

*To*: cme@cybercash.com (Carl Ellison)*Subject*: Re: public key algorithm naming*From*: fredette@theory.lcs.mit.edu (Matt Fredette)*Date*: Wed, 8 Apr 1998 10:49:28 -0400 (EDT)*Cc*: spki@c2.net*In-Reply-To*: <3.0.3.32.19980407143739.00a8e3f0@cybercash.com> from "Carl Ellison" at Apr 7, 98 02:37:39 pm

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

**Re: public key algorithm naming***From*: Carl Ellison <cme@cybercash.com>

**Re: public key algorithm naming***From*: Carl Ellison <cme@Cybercash.COM>

- Prev by Date:
**Re: public key algorithm naming** - Next by Date:
**Re: public key algorithm naming** - Prev by thread:
**Re: public key algorithm naming** - Next by thread:
**Re: public key algorithm naming** - Index(es):