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

*To*: ekr@terisa.com*Subject*: Re: public key algorithm naming*From*: fredette@theory.lcs.mit.edu (Matt Fredette)*Date*: Tue, 7 Apr 1998 13:34:39 -0400 (EDT)*Cc*: cme@Cybercash.COM, fredette@theory.lcs.mit.edu (Matt Fredette), spki@c2.net

> Message-Id: <3ogyelfij.fsf@kmac.terisa.com> > > 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? Yeah, I had a hard time presenting that bit. It's both a quote of Carl and something that I agree with. Carl helped me out with: ] Message-Id: <3.0.3.32.19980407104609.00b082e0@cybercash.com> ] ] Eric, ] ] Matt's wording was a little muddled here. PKCS-1 *is* the encoding ] algorithm he was talking about. ] ] What you and I agreed was that the PKCS-1 needs to be specified. ] If all you specify is "rsa", then I have an unpacking algorithm that can ] pull the hash of my own construction out of an RSA-PKCS1 block. Right. > > 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. Allowing both doesn't bother me, but that's just me. What kind of problems do you see? > > - 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: OK, I agree, and note that the algorithm used is still available separately in the current grammar, in the <hash> in <signature>. ] >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. ] ] Are you suggesting we should write and name our own packing algorithm? ] ] What does PKIX call its algorithm? ] ] - Carl I guess it's bad foresight that they talked about two things (message padding and key encoding) in one document. But since it's very clear in SPKI that we only use an S-expression format for RSA keys, typing those S-expressions rsa-pkcs1, to talk about the message padding, also doesn't bother me. It's not 100% crystal clear, but it's not too bad. 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>

- 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):