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

*To*: fredette@theory.lcs.mit.edu (Matt Fredette)*Subject*: Re: public key algorithm naming*From*: EKR <ekr@terisa.com>*Date*: 06 Apr 1998 16:03:16 -0700*Cc*: spki@c2.net*In-Reply-To*: fredette@theory.lcs.mit.edu's message of "Mon, 6 Apr 1998 18:10:37 -0400 (EDT)"*References*: <199804062210.AA02783@magpie.lcs.mit.edu>*Sender*: owner-spki@c2.net

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

**Re: public key algorithm naming***From*: Carl Ellison <cme@Cybercash.COM>**Re: public key algorithm naming***From*: Marc Branchaud <marcnarc@xcert.com>

**Re: public key algorithm naming***From*: fredette@theory.lcs.mit.edu (Matt Fredette)

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