ietf-smime
[Top] [All Lists]

RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt

2008-08-20 14:52:26

Tony,

I incorporated these comments in a version I'm about to post.  Minor tweaks
to the text for the CERT security considerations.

spt

-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com] 
Sent: Friday, August 08, 2008 3:41 PM
To: 'Turner, Sean P.'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 

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.
| >
| 


<Prev in Thread] Current Thread [Next in Thread>