Sean:
From the mail discussion we had in December, it's pretty clear to me that
key sizes from 1024-2048 ought to be the MUST and other key sizes are MAY.
I'm suggesting the following text:
Key sizes from 1024 bits to 2048 buts MUST be supported. Keys sizes larger
than 2048 MAY be supported.
s/buts/bits/
Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?
I think we ought to be forgiving on receive. Thus, I suggest:
Message originators SHOULD NOT use key sizes smaller than 1024 bits
for private key operations.
Recommendations for key sizes depend on the usage of the key.
If the private key is to be used to sign data in the context of an
authentication service
or a non repudiation service, then the private key shall resist during the
validity
period of the certificate (usually one to three years).
If the key size has been chosen too small, there is no security breach:
it is only needed to revoke the certificate.
If the private key is to be used to decrypt data, than the key should resist
as long as the encrypted data should be kept confidential.
RFC 3161 is using S-MIME. If the key is to be used for a Time Stamping Unit
(TSU),
it had better to resist quite longer and 2048 bits would be recommended.
These kinds o recommendations should be included in the security considerations
section.
As far as interoperability is concerned the current text is:
"A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits".
This key size is still safe for authentication and non repudiation and thus
there is no reason to raise this value.
Russ
Denis