At 10:47 AM -0700 5/13/08, Luther Martin wrote:
> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
> 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.