RE: I-D ACTION:draft-santesson-smime-scext-00.txt
"Tony Capel" <capel@comgate.com> Wed, 01 September 2004 18:51 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20784 for <smime-archive@lists.ietf.org>; Wed, 1 Sep 2004 14:51:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IYUTn093634; Wed, 1 Sep 2004 11:34:30 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81IYUKD093633; Wed, 1 Sep 2004 11:34:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81IYTDl093626 for <ietf-smime@imc.org>; Wed, 1 Sep 2004 11:34:30 -0700 (PDT) (envelope-from capel@comgate.com)
Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx1.magmacom.com (8.13.0/8.13.0) with ESMTP id i81IYWUN012498; Wed, 1 Sep 2004 14:34:33 -0400
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail2.magma.ca (8.13.0/8.13.0) with ESMTP id i81IYNR4023289; Wed, 1 Sep 2004 14:34:32 -0400
From: Tony Capel <capel@comgate.com>
To: ietf-smime@imc.org, stefans@microsoft.com
Cc: 'Anders Rundgren' <anders.rundgren@telia.com>
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt
Date: Wed, 01 Sep 2004 14:36:32 -0400
Message-ID: <002901c49052$9e14ae50$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <00ba01c48047$3571cba0$0500a8c0@arport>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i81IYUDl093628
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>
Content-Transfer-Encoding: 8bit
Stefan: I am also concerned about requiring that the sMIMECapabilities be in the certificate itself, although I agree that something to help get initial sMIMECapabilities is required. Jim Schaad's "Certificate Distribution Specification" expired draft (draft-ietf-smime-certdist-05.txt) touched on this as well. If sMIMECapabilities is bound to the certificate, certificates may need to be re-issued more frequently (when capabilities information is changed). This will create additional work for the CA, and CRLs will inevitably increase in size (these are bad things). (Correct me if I am wrong: If the capabilities for an organization changes, all of the certs will need to be reissued!) Also since the certificate is signed by the CA, sMIMECapabilities in this proposal is signed by the CA and not the end-entity (as in existing method). This may sometimes be beneficial since it allows the CA to have added control over the use of algorithms and key lengths. The change from the end-user signing to the CA signing has security implications and should be noted* (possibly in the security section). Some of the issues could be addressed by allowing the use of a dynamic method as well. One or more methods could be specified, XKMS + DNS, LDAP, and/or HTTP for example. One available method could be an "immediate" method, allowing those CAs who do not mind putting sMIMECapabilities within their certificates to do so (as currently proposed). I also wonder how many cases there are when only the sMIMECapabilities is required (and not certificates & paths as well). If you don't have a certificate, an extension won't help (you need certificates and sMIMECapabilities both). If you have a certificate from a previous message you likely also received the sMIMECapabilities in a SignerInfo. If you obtained the certificate using LDAP or some other means you might logically but arguably expect to access the sMIMECapabilities the same way. If your software threw away the S/MIME capabilities (rather than caching them like the certificate) adding them to the certificate is a peculiar way to fix the software! Also of course for dual keypair systems, there may be situations where you have the signing certificate but not the encryption one, in which case you want both sMIMECapabilities and the encryption cert - and I hope the proposal is not to embed the encryption cert inside the signing cert!!! So maybe the method used to get sMIMECapabilities should also be able to return the certificates & paths - to make it more generally useful - in which case Jim Schaad's proposal - and allowing any dynamic access method including XKMS + DNS, LDAP, HTTP, . - may be worth another look. Sorry for the long winded reply. But an easier method to get certs, paths and sMIMECapabilities is needed. Tony * This may also include a discussion about using values provided in certificates in preference to values obtained by other means (e.g. when both a certificate and the SignerInfo contain sMIMECapabilities). For example, the first paragraph of Section 3 in the current proposal may not always be correct: the sMIMECapabilities list signed by the CA (e.g. provided in a certificate) may be more trusted than the list provided in a message even if it appears the message was more recent. In some applications the increased trust (or more correctly, the increased authority of the signor) may take preference. | -----Original Message----- | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Anders Rundgren | Sent: August 12, 2004 4:35 AM | To: ietf-smime@imc.org | Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt | | | | I have no comments on the "design" in this draft. | | However, I seriously question the idea to put client software | capabilities in certificates. | | Why? | - because issuers may not have this information | - because users may have multiple clients | - because static solutions are limiting | | If we begin to use dynamic methods like XKMS + DNS to find | public keys of recipients, SCEXT represents a step in another | direction. | | Due to the limited utility of true end-to-end encryption in | corporate environments (the DOMSEC RFC shows a few good | reasons to that), as well as the de-facto use of the web as a | distribution medium for e-government purposes (which is a | much easier solution than S/MIME), I believe that Microsoft | should focus on making a gateway e-mail standard a reality | rather than patching a system that never will play a major | role and actually mostly creates problems for end-users and | system administrators. | | Anders | |
- I-D ACTION:draft-santesson-smime-scext-00.txt Internet-Drafts
- Re: I-D ACTION:draft-santesson-smime-scext-00.txt Anders Rundgren
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Tony Capel
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Tony Capel
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- Re: I-D ACTION:draft-santesson-smime-scext-00.txt Denis Pinkas
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- Re: I-D ACTION:draft-santesson-smime-scext-00.txt Denis Pinkas
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Tony Capel
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Tony Capel
- RE: I-D ACTION:draft-santesson-smime-scext-00.txt Stefan Santesson
- Static vs Dynamic sMIMECapabilities draft(s) Sean P. Turner
- RE: Static vs Dynamic sMIMECapabilities draft(s) Tony Capel
- Re: Static vs Dynamic sMIMECapabilities draft(s) Sean P. Turner