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

*To*: spki@c2.net*Subject*: Re: public key algorithm naming*From*: fredette@theory.lcs.mit.edu (Matt Fredette)*Date*: Mon, 6 Apr 1998 18:10:37 -0400 (EDT)*Sender*: owner-spki@c2.net

> Message-Id: <3.0.3.32.19980314020906.00a55100@cybercash.com> > > Eric, > > thanks for the discussion. > > I'd like to hear from others in the group as well. If it's just ` > the two of us, interested in this, we can have lunch in LA and work it out > between us. > > - Carl I just reread all of this thread. Here's what I've got: [snip] > Message-Id: <199803122141.AA09925@magpie.lcs.mit.edu> > > IMO, the hash algorithm you use to sign is as important a part of "you" > as your key parameters are. It serves to define you as much as anything, > in the digital world, where everything comes from signatures. Listing > your hash algorithm beside your key parameters gives it this important > meaning - since keys get signed as parts of certificates and are also > listed in ACLs. The way I see it, a signature from someone with your > same key parameters but using a different hash function is not you. > > Matt This dates to the days, not so long ago :o, when I didn't know that PKCS-1 encodes the hash algorithm name into the value that is signed. Now that I know that, my view of the world has changed a lot. [snip] 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. I'm assuming that everyone buys this (I do). [snip] > Message-Id: <3.0.3.32.19980313104444.00a48830@cybercash.com> > > > - Carl > > P.S. If we end up following your suggestion, of divorcing the > hash algorithm from RSA key specifications, then that <sig-val> could > hold the hash algorithm for informational use only. In fact, > I realize now that the BNF does not need to change in response to the > decision we make on this item ... Right. To take the "informational" idea a little bit farther, I think that <sig-val> should *never* hold the hash algorithm name when it can be inferred (= it was specified as part of the signing key's name) or recovered (= the encoding used by the signing key includes it). I.e., I think that the part of Section 3.8.3.1 <sig-val> in draft-ietf-spki-cert-structure-05.txt that reads: 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> ")" ; should be removed. This keeps all old signatures and signature parsers valid. [snip] > Message-Id: <199803130009.QAA01360@itech.terisa.com> > > > On the other side of this, Ron Rivest far prefers to declare them up front. > > > That wasn't quite what I understood Ron's position to be. Maybe we could > get Ron to take a crack at explaining himself. Ron? [snip] 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. - 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. For dsa-sha1, <sig-val> is a <dsa-sig-val>: <dsa-sig-val>:: "(" "dsa-sha1-sig" "(" "r" <byte-string> ")" "(" "s" <byte-string> ")" ")" ; The patch release of my code coming out sometime this week will behave this way. 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*: EKR <ekr@terisa.com>**Re: public key algorithm naming***From*: Carl Ellison <cme@Cybercash.COM>

- Prev by Date:
**Re: [E-CARM] PKI, CAs, TTPs &c.** - 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):