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

RE: S/MIME v3.2 IDs key size text


At 10:47 AM -0700 5/13/08, Luther Martin wrote:

 > -----Original Message-----
 > From: owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-smime@xxxxxxxxxxxx]
 > On Behalf Of Paul Hoffman
 > >In the
 > >case of two of the three above the justification given was some variation
 > on
 > >"if these really were no good then they'd be explicitly disallowed.
 > Since
 > >they aren't, it's perfectly OK to do this".
 >
 > I'm skeptical, to say the least. If you have actual quotes of people
 > saying that, fine; quoting someone third-hand through an IETF
 > security geek is not a good way to get accurate results.

I'm with Peter on this one.
I don't want to try to one-up Peter's stories (although I might be able to), I've also seen all sorts of blunders caused by people unfamiliar with public-key technology not understanding things that everyone on this list almost certainly takes for granted. I'd guess that most people who have worked with users of public-key technology for any length of time have a similar set of stories.
Of course this is true. What I question is Peter's assertion that putting a "don't be stupid" clause in the S/MIME RFC will cause any of them to be less stupid. In order to believe that, I want to hear someone say "I read the RFC and I still made this decision". I doubt that is true because I doubt any of these folks read the RFC.
I've also seen people wanting to do make all sorts of crypto-blunders to make things easier to use, more efficient, or to comply with the letter of regulations instead of the spirit.
So explicitly banning things that might qualify as such blunders is probably a very good idea.
Maybe so, but that's not what Peter was advocating. I'm pretty sure he was supporting a statement that applications MUST NOT validate signatures that are 511 bits long while allow applications to validate signatures that are 512 bits long.