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

"Tony Capel" <capel@comgate.com> Mon, 11 August 2008 15:11 UTC

Return-Path: <owner-ietf-smime@mail.imc.org>
X-Original-To: ietfarch-smime-archive@core3.amsl.com
Delivered-To: ietfarch-smime-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868543A6CE2 for <ietfarch-smime-archive@core3.amsl.com>; Mon, 11 Aug 2008 08:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.508
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF3QKJxBXlaM for <ietfarch-smime-archive@core3.amsl.com>; Mon, 11 Aug 2008 08:11:27 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 256723A65A6 for <smime-archive@ietf.org>; Mon, 11 Aug 2008 08:11:27 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (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 owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BEsM4O036831; Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from mail-01.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BEsLvN036813 for <ietf-smime@imc.org>; Mon, 11 Aug 2008 07:54:21 -0700 (MST) (envelope-from capel@comgate.com)
Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-01.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from <capel@comgate.com>) id 1KSYmq-0000SS-1l; Mon, 11 Aug 2008 10:54:20 -0400
From: Tony Capel <capel@comgate.com>
To: "'Turner, Sean P.'" <turners@ieca.com>, ietf-smime@imc.org, "'Hoffman, Paul'" <paul.hoffman@vpnc.org>
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
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=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
| >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