Paul Hoffman <phoffman(_at_)imc(_dot_)org> writes:
You'll need to justify this one, Peter. Show me some examples where any
previous version of S/MIME, none of which have "sane" lower limits, was used
by any organization to justify a stupid key size.
How many would you like? Without naming names (if anyone really insists I
could perhaps name them in private), there's an organisation using 128-bit RSA
keys for access control to significant amounts of power switching gear because
everyone knows that 128-bit keys are good so it should be fine for RSA. Since
this is in the US I'm not that fussed about someone using it to take out their
power transmission systems :-), but I think some other people might be. Uhh,
Canadian health board using RSA in ECB mode to encrypt patient data, and they
ended up using either 128- or 64-bit keys because otherwise things ran too
slowly. Signing using 384-bit keys by a european government organisation...
how many do you want, and how long have you got? I haven't got them all
committed to memory so I'd have to dig back through old email and whatnot.
I realise these aren't all specificially for S/MIME (the signing one was, at
least for PKCS #7) but they're examples of just what people will do if the
standards don't disallow it. A number of the examples came from talking to
other IETF security folks so there's probably a lot more like this floating
around (every time I post one of these horror-story comments I tend to get a
bunch of email saying "That's nothing, you should hear this one..."). 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".
Please suggest specific text that would meet your criteria.
The original (proposed) MUST NOT text. There's no point in verifying a
signature that you know is insecure because you know no more about the
validity of the data after the verification than you did before. If the
signature can't tell you anything about the validity of the data that's been
signed then it should be rejected as an invalid signature because it's not
serving the purpose for which it was intended.
Peter.