Hi Alfred,
The lower bound was dropped for a couple of reasons. Practically
speaking,
any RSA/DSA keys smaller than 1024 bits offer little security.
Setting any lower bound
seems to imply that there is a significant break point, and I did not
want to give
that implication. I also thought that implementations might want to
set a more
aggressive bound (e.g., 768 bits) and leaving off the lower bound might
encourage making an explicit choice rather than supporting 512
because it
was specified in the table.
Perhaps the right thing would be to add one more sentence in each of the
security considerations sections.
For 3850bis:
Note that previous versions of this standard set the lower bound for
RSA and DSA key
sizes at 512 bits; implementations that support verification of
certificates or CRLs
generated with weak keys MUST NOT support RSA or DSA keys of less
than 512 bits.
For 3851bis:
Note that previous versions of this standard set the lower bound for
RSA and DSA key
sizes at 512 bits; implementations that support verification of
digital signatures
generated with weak keys MUST NOT support RSA or DSA keys of less
than 512 bits.
Would that address your concern?
Thanks,
Tim Polk
On Jan 7, 2009, at 6:16 AM, Alfred HÎnes wrote:
Folks,
I agree with Paul with regard to the process (new I-D preferable).
The AD proposed changes at first glance are intended to make the
requirements *stronger* (as far as possible without relying on
an official version of FIPS PUB 186-3) without sacrificing
backwards compatibility.
Therefore, I agree with the amended Security Considerations text,
for both 3850bis and 3581 bis, and the changes proposed for
receiving agent (signature verifier) behavior -- although these
now allow small key sizes (< 512) which were not allowed by
RFC 3850, and hence this change comes a bit to surprise.
However, I really do not understand why, at the 'low end', signature
*generating* agents shall now be allowed (via 'MAY') to generate
signatures with the even worse key sizes < 512, for both RSA and DSA.
Since already S/MIME v3.1 agents had no requirement for being able
to verify such signatures, why now adding the capability to produce
such signatures ?
Finally, nits for 3851bis, in (1) / Section 4.2 :
- I suggest s!generated!generating!
- Also, for alignment with (2) / Section 4.3,
it might be preferable to use plural:
s!an S/MIME agent!S/MIME agents!
Kind regards,
Alfred.
--
+------------------------
+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-
Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax:
-18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-
Sys.de |
+------------------------
+--------------------------------------------+