-----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)? 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.
Tony
*Abstract from KEYM:
"Implementers should be aware of risks involved if the CRL
distribution points or authority information access extensions of
corrupted certificates or CRLs contain links to malicious code.
Implementers should always take the steps of validating the
retrieved
data to ensure that the data is properly formed."
** See GeoTrust Universal CA in both MS and Mozilla root stores.