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

"Tony Capel" <> Mon, 11 August 2008 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 868543A6CE2 for <>; Mon, 11 Aug 2008 08:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.508
X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RF3QKJxBXlaM for <>; Mon, 11 Aug 2008 08:11:27 -0700 (PDT)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 256723A65A6 for <>; Mon, 11 Aug 2008 08:11:27 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m7BEsMZ4036832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id m7BEsM4O036831; Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id m7BEsLvN036813 for <>; Mon, 11 Aug 2008 07:54:21 -0700 (MST) (envelope-from
Received: from ([] helo=tony) by with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from <>) id 1KSYmq-0000SS-1l; Mon, 11 Aug 2008 10:54:20 -0400
From: Tony Capel <>
To: "'Turner, Sean P.'" <>,, "'Hoffman, Paul'" <>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
Date: Mon, 11 Aug 2008 10:54:09 -0400
Message-ID: <2A69EF0090F34CC8A84A3643CA55CC86@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
In-Reply-To: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie>
Importance: Normal
Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWgAInBViA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

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


* i.e. the perpetrator could set up a CA and generate these certificates.