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

"Turner, Sean P." <turners@ieca.com> Sat, 09 August 2008 23:07 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 505F53A6A71 for <ietfarch-smime-archive@core3.amsl.com>; Sat, 9 Aug 2008 16:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 6XcH8Bnk7h7g for <ietfarch-smime-archive@core3.amsl.com>; Sat, 9 Aug 2008 16:07: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 457FA3A69E2 for <smime-archive@ietf.org>; Sat, 9 Aug 2008 16:07: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 m79Mjrjj003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 15:45:53 -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 m79MjrPK003603; Sat, 9 Aug 2008 15:45:53 -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 smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m79MjoAF003588 for <ietf-smime@imc.org>; Sat, 9 Aug 2008 15:45:52 -0700 (MST) (envelope-from turners@ieca.com)
Received: (qmail 48529 invoked from network); 9 Aug 2008 22:45:50 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.115.214 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 9 Aug 2008 22:45:50 -0000
X-YMail-OSG: gNZnZd4VM1kcdxDO.JNCueMvaUqfkb32tgYVmGN_utvvuYGL4m5u0SagmgFS6hPvs_Iz6xVhCxD0d8lWKFuSdml9bK1Te4ic0e0A49QNog--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <turners@ieca.com>
To: 'Tony Capel' <capel@comgate.com>, ietf-smime@imc.org, "Hoffman, Paul" <paul.hoffman@vpnc.org>
References: <31B9D22ECA884473981B83F00F05ECA5@Wylie> <F5BB65D9E2AA4ED4A918B61E7A0C8519@tony>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
Date: Sat, 09 Aug 2008 18:45:42 -0400
Organization: IECA, Inc.
Message-ID: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
In-Reply-To: <F5BB65D9E2AA4ED4A918B61E7A0C8519@tony>
Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWg
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)?  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.
>