0 *H 01 0 +0 *H $SContent-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sean et al: How about: 0 < key size < 512 : MAY but refer to security considerations section 512 <= key size < 1024 : SHOULD- but refer to security considerations section 1024 <= key size <= 2048 : MUST 2048 < key size : MAY but refer to security considerations section For larger keys, some text for the security considerations section might be added, e.g. something like: "A denial of service opportunity may exploitable by attackers who provide an excessively large key, or a key selected to require excessive cryptographic processing. One mitigation approach would require that the corresponding public key certificate be validated to a trusted root [trust anchor] prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or data encryption) in parallel with certificate validation, or even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys." For smaller keys, this is already addressed to some extent for encryption in the security considerations section, maybe this needs updating based on our experience with smime: Current text: 40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents SHOULD inform senders and recipients of the relative cryptographic strength of messages. Proposed Draft text: "Using weak cryptography in S/MIME offers little actual security over sending plaintext. Some cryptographers consider public keys of less than 1024* bits to be weak, along with symmetric encryption algorithms of less than 64 bits and certain older hash algorithms used for signing. In any given application, an appropriate analysis of the threats and risks SHOULD lead to the selection of appropriate algorithms and key sizes. For public keys, algorithms and key sizes are normally defined by the public key issuer in the corresponding certificate, and thus not under the control of the end user. For symmetric encryption and hash algorithms, S/MIME supports the ability of parties to communicate their capabilities to each other, allowing the use of appropriately strong measures. When feasible, sending and receiving agents SHOULD inform senders (prior to transmission) and recipients of the relative cryptographic strength of messages and SHOULD provide a warning if weak algorithms or key sizes are used. Such warnings are especially important if the symmetric encryption or hash algorithm are significantly weaker than the corresponding public key, since this will result in a message with weaker security than that implied by the public key certificate. " Tony * of course this could be a smaller value. | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Timothy J Miller | Sent: May 12, 2008 9:31 AM | To: Paul Hoffman | Cc: Turner, Sean P.; ietf-smime@imc.org | Subject: Re: S/MIME v3.2 IDs key size text | | | | On May 9, 2008, at 4:40 PM, Paul Hoffman wrote: | > | > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote: | >> | >> 0 < key size < 511 : MUST NOT | >> 512 < key size < 1023 : SHOULD- | | > Beyond what Russ just pointed out, I find the first line to be in | > bad taste. Any IETF spec that says "you must not be able to | verify a | > signature even though it is valid" is pretty offensive. | | How about adding a "MUST warn the user that key is too damn short to | be considered safe, even though the signature is valid" | clause instead? | | -- Tim | |  R005k/"tal0  *H 0_1 0 UUS10U VeriSign, Inc.1705U .Class 1 Public Primary Certification Authority0 051028000000Z 151027235959Z01 0 UUS10U VeriSign, Inc.10U VeriSign Trust Network1;09U 2Terms of use at https://www.verisign.com/rpa (c)0510U Persona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G20"0  *H 0 ߬~6<|r=o,?&C?GGL>Tl0p@DzK`:eb{VNp-֢ZIl وuy`'ݹu/sz@:uIhP< S0o2FIly۴00U00DU =0;09 `HE0*0(+https://www.verisign.com/rpa0 U0 `HB0.U'0%#0!10UPrivateLabel3-2048-1550U}^}<jl֢?1;R01U*0(0&$" http://crl.verisign.com/pca1.crl0U#z0xca0_1 0 UUS10U VeriSign, Inc.1705U .Class 1 Public Primary Certification AuthorityͺVT"rU0  *H /ٖᒢ`* g,SKDFҿJMCʻI!s3WBZ1N]-p`ńFA }~~x'@:\s|fW᤭qwz Z0 )U0MKI~R/~閴ֺzKX9p)vnEYІ1kN)%B'[ܤ*׾ASxShn'%VD7k#RXZ@#V!m^ԑGS׉OfCzxޥ5+1+ηH'6y00 U00DU =0;09 `HE0*0(+https://www.verisign.com/rpa0 U0U%0++00 `HE" 7158c2938e2d1d0dd19c1043027d3b1e0JUC0A0?=;9http://IndC1DigitalID-crl.verisign.com/IndC1DigitalID.crl0  *H ّVYڒ%LLC,!5"> g(f$Gh:Ķ`84uQUKݢpuDޢA0#Uߡy_JE5I-^hoA$`Ѡ>Z X`LuqLFmDl;̔⃜ÜUTNOfTd.ZG|="