[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: public key algorithm naming
> 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."
Follow-Ups: