|
| >-----Original Message-----
|
| Snip
|
| >Some possible text (for CERT only):
| >
| >"In addition to the Security Considerations identified in
| >[KEYM], caution should be taken when processing certificates
| >which have not first been validated to a trust anchor.
| >Certificates could be manufactured by untrusted sources for
| >the purpose of mounting denial of service or other attacks.
| >For example, keys selected to require excessive cryptographic
| >processing, or extensive lists of CDP and/or AIA addresses in
| >the certificate, could be used to mount denial of service
| >attacks. Similarly, originator-specified CDP and/or AIA
| >addresses could be inserted into certificates to allow the
| >originator to detect receipt of the message even if signature
| >verification fails."
| >
| >The above would just identify the concern, not offer any
| >solutions - I suggest leaving how to be cautious up to the
| >implementer!
|
| Since Paul's replacement text removes the part about path
| validation I like the idea of moving it to CERT. Not sure I
| understand the last sentence (how is the originator going to
| insert fields in their certificate)?
"Insert" may have been a misleading. I meant that its pretty
easy* for an originator to create an end user cert
(and possibly zero or more intermediate certificates)
with selected content (including bad keys, arbitrary CDP/AIA
URI entries, etc.)). These would not validate to a trust
anchor, but IF they are processed anyway, the originator could
get a receiver to use a large key, execute a specified URI, etc.
So for CERT the problem is not only bad keys.
I do not suggest addressing anything other than bad keys in
MSG, since I think the above additional issues (other certificate
content) is a CERT processing issue not an MSG issue. (For MSG its
only the use of a key requiring excessive processing, and
the mitigation measures are related to MSG crypto processing
and your point about time-out is good for MSG.)
| I also don't want to
| loose the ideas that we had in MSG about ensuring only
| trusted keys are used before use and that a time-out isn't a
| bad idea. That is I'd like to keep the following text:
|
| One approach would require that the corresponding public key
| certificate be validated to a trust anchor prior to use, thus
| ensuring that only trusted public keys are used. However,
| some implementations may choose to perform signature
| verification (or key establishment for encryption) in
| parallel with certificate validation, 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.
|
| >Finally, I am still concerned that we are not making support
| >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION
| >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice
| >this size is widely supported today, e.g. both MS and Mozilla
| >have many 4k certs in their root stores**.
| >The discussion here is verification only, NOT signature
| >generation or decryption
| >- mandating support for these I agree needs to be limited to
| >2k; the typical crypto size limit for hardware tokens.
| >However, signature verification is not normally done in the
| >token anyway; so this is not an issue. In practice many
| >authorities are going to 4k root certs because they want to
| >issue them with long lifetimes (longer than end user certs, so
| >shorter keys in end user certs are ok). We need to make sure
| >common e-mail clients building to v3.2 can work with these
| >common new 4k RSA root certs. This comment ONLY affects
| >support for cert signature processing (3850bis section 4.3,
| >and even then maybe only for Certificates, not CRLs).
|
| Unless I've misread my email from before, Paul objected to
| having requirements on the verifiers that are in excess of
| the signers and that it's really more of a current practice
| as opposed to an interoperability requirement. Paul correct
| me if I'm wrong.
This does not impose differing requirements on smime signers and
verifiers. I think both smime signers and verifiers need 4k
support for certificate (and CRL) verification only. I expect
these 4k certificates and CRLs to be created by certificate
authorities so only they need to create the 4k signatures.
Tony
* i.e. the perpetrator could set up a CA and generate these certificates.
cut