Sean:
I know you will be putting in some text to address Jim (and my) request for text
re key sizes > 4096 for CERT 3850bis.
A directly related security concern, and one that has been around for some time,
is the potential for other inappropriate processing if an offered end entity
cert (or any offered cert in the chain) is processed prior to, or irrespective
of, being validated to a trusted root. In addition to the problem of a large
key, there is the potential of inappropriate CDP (and/or AIA) defined action
(e.g. web access to an inappropriate address). Rfc5280 [KEYM] has a comment*
about making sure that such an action does not download malicious code, but in
practice even correctly formed CDP/AIA access(es) could raise denial of service
or privacy concerns. Normally a user agent will time out on an invalid CDP/AIA
address; but certificates can contain many addresses.... Also, the CDP/AIA
address could point to a special address defined by the originator, e.g.
allowing a spammer to validate receipt of a signed message (even if the
signature fails).
So I wonder, for CERT, whether it would be best to be more general when
identifying these security concerns so that issues in addition to the key size
are included?
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!
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).
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.
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Turner,
Sean P.
| Sent: July 28, 2008 4:18 PM
| To: ietf-smime(_at_)imc(_dot_)org
| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
|
|
|
| Other things Jim requested offline:
| - Point to PKIXALG as opposed to CMSALG, which makes sense
| since this is the CERT ID.
| - Add back in changes from v3 to v3.1, which also makes
| sense because the section should not have been removed.
|
| spt
| >-----Original Message-----
| >From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
| >Sent: Monday, July 28, 2008 2:43 PM
| >To: Sean P. Turner; 'Blake Ramsdell'
| >Cc: ietf-smime(_at_)imc(_dot_)org
| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
| >
| >Comments on the draft.
| >
| >In section 4.4.3, I find the following text confusing:
| >
| >End-entity certificates contain an extension that
| > constrains the certificate from being an issuing authority
| > certificate (see Section 4.4.2).
| >
| >
| >I believe that this text might be better as it clarifies what
| >is being stated. I.e. it is not the fact that basic
| >constraints is being used which actually does the mentioned
| constraint.
| >
| >
| >End-entity certificates contain the Key Usage extension which
| >restraints the end-entity from using the key to perform
| >issuing authority operations (see
| >4.4.4)
| >
| >Also the previous comment (on 3851bis) on key sizes > 4096
| >should be applied to this document
| >
| >jim
| >
| >> -----Original Message-----
| >> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
| >> smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Internet-Drafts(_at_)ietf(_dot_)org
| >> Sent: Tuesday, July 01, 2008 1:30 AM
| >> To: i-d-announce(_at_)ietf(_dot_)org
| >> Cc: ietf-smime(_at_)imc(_dot_)org
| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
| >>
| >> A New Internet-Draft is available from the on-line Internet-Drafts
| >> directories.
| >> This draft is a work item of the S/MIME Mail Security
| >Working Group of
| >> the IETF.
| >>
| >> Title : Secure/Multipurpose Internet Mail Extensions
| >> (S/MIME) Version 3.2 Certificate Handling
| >> Author(s) : S. Turner, B. Ramsdell
| >> Filename : draft-ietf-smime-3850bis-04.txt
| >> Pages : 20
| >> Date : 2008-6-30
| >>
| >> This document specifies conventions for X.509 certificate usage by
| >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.
| >> S/MIME
| >> provides a method to send and receive secure MIME messages, and
| >> certificates are an integral part of S/MIME agent processing.
| >> S/MIME agents validate certificates as described in RFC
| 3280bis, the
| >> Internet X.509 Public Key Infrastructure Certificate and CRL
| >> Profile.
| >> S/MIME agents must meet the certificate processing
| requirements in
| >> this document as well as those in RFC 3280bis. This document
| >> obsoletes RFC 3850.
| >>
| >> A URL for this Internet-Draft is:
| >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
| >>
| >> Internet-Drafts are also available by anonymous FTP at:
| >> ftp://ftp.ietf.org/internet-drafts/
| >>
| >> Below is the data which will enable a MIME compliant mail reader
| >> implementation to automatically retrieve the ASCII version of the
| >> Internet-Draft.
| >
|