From owner-ietf-smime@imc.org Mon Oct 4 10:08:12 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02201 for ; Mon, 4 Oct 1999 10:08:11 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id GAA04580 for ietf-smime-bks; Mon, 4 Oct 1999 06:20:04 -0700 (PDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA04576 for ; Mon, 4 Oct 1999 06:20:03 -0700 (PDT) Received: from Dell (dyn-1-1-229.Cor.dialup.oleane.fr [62.161.8.229]) by s2.smtp.oleane.net with SMTP id PAA84332; Mon, 4 Oct 1999 15:21:14 +0200 (CEST) Message-ID: <006c01bf0e6b$5491e400$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: From Firewall to IPSec VPNs Date: Mon, 4 Oct 1999 15:21:11 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01BF0E7C.16E36C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0069_01BF0E7C.16E36C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm ------=_NextPart_000_0069_01BF0E7C.16E36C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Security services and protection mechanisms
IPv6 promises = regarding=20 IPSec
Certification infrastructure
Standardization update
Case = Studies:=20 ISPs, carriers, private networks
AH and ESP protocols = description
Possible=20 future extensions and modifications of the IKE = protocol
Complementarity=20 between IPSec and firewalls
Global Site-to-Site IPSec VPN's with = End-to-End=20 SLA's
Managing widespread IPSEC virtual private networks
Solving = IPSec=20 VPNs scalability
Results of some interoperability tests
IPSec=20 architectures and non-standardized aspects of IPSec
Adding IPSec VPN=20 functions in an existing router network
Impact of fragmentation on = the=20 performance of IPSec coding

IPSEC 99 Conference
From Firewall = to IPSec=20 VPNs

October 26, 27, 28, 29, 1999
Paris - France

More = infos: www.upperside.fr/baipsec.htm=
 
------=_NextPart_000_0069_01BF0E7C.16E36C80-- From owner-ietf-smime@imc.org Mon Oct 11 16:25:45 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14335 for ; Mon, 11 Oct 1999 16:25:44 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id MAA09220 for ietf-smime-bks; Mon, 11 Oct 1999 12:47:12 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09215 for ; Mon, 11 Oct 1999 12:47:11 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HK0>; Mon, 11 Oct 1999 12:48:24 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Walter Williams'" , "'Russ Housley'" Cc: "'wpolk@nist.gov'" , "'ietf-smime@imc.org'" Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:48:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keyboard focus bug -- lets finish the message this time. I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if there are sufficent pointers in the certificate to allow it to be found. (i.e. an AIA extension with an ldap URI). I will update the draft to this and post before the end of the week. jim -----Original Message----- From: Jim Schaad (Exchange) Sent: Monday, October 11, 1999 12:46 PM To: 'Walter Williams'; Russ Housley Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if -----Original Message----- From: Walter Williams [mailto:walter.williams@gte.com] Sent: Sunday, September 12, 1999 7:30 PM To: Russ Housley; jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Russ, One thought here is backwards compatability of existing s/mime aware clients. Some may have been written to check for the cert in only one of the available attributes. You don't want to change the directory in a way which prevents an older client from seeing the certificate. (might though give vendors a thrill to have to say: so sorry, but due to a standard change we must force you to upgrade to support s/mime again) Certificates are also not very large (compaired with a .jpg picture of the directory entrant as a comparitive example) and so the data bloat does not waste much drive space. Of course, if all available clients look in both places, my statement is pretty much a waste of good bandwidth. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Russ Housley Sent: Sunday, September 12, 1999 12:35 PM To: jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Jim: I must agree with many of the points that Dave Kemp made. Is it worth putting multiple copies of the same certificate into the Directory? This can lean to inconsistincies. Maybe it would be better to follow the PKIX LDAP Schema and add an S/MIME-specific attribute too the directory entry. The binding you seek could be achieved by putting a reference to a specific certificate that is available in the userCertificate attribute inside the S/MIME-specific attribute. Thoughts? Russ From owner-ietf-smime@imc.org Mon Oct 11 16:26:13 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14369 for ; Mon, 11 Oct 1999 16:26:12 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id MAA09135 for ietf-smime-bks; Mon, 11 Oct 1999 12:42:08 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09131 for ; Mon, 11 Oct 1999 12:42:07 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HDJ>; Mon, 11 Oct 1999 12:43:20 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Russ Housley'" Cc: ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:43:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Use of this element has what I consider to be a fatal flaw -- specifically it is not protected in any way. There is nothing to prevent me from changing the value that you see retrieved from the directory in such a way to allow you to detect it. (consider changing the algorithms from 3DES to RC2/40 for example). After all, as a rule one does not bother looking up ones own data in a directory to see if it has been changed recently. jim -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Thursday, September 16, 1999 9:51 AM To: jimsch@EXCHANGE.MICROSOFT.com Cc: ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST X.509-1997 defines the supported algorithm attribute. There seems to be a lot of overlap. Russ = = = = = = = = = = 12.2.2.8 Supported algorithms attribute A Directory attribute is defined to support the selection of an algorithm for use when communicating with a remote end entity using certificates as defined in this Directory Specification. The following ASN.1 defines this (multi-valued) attribute: supportedAlgorithms ATTRIBUTE ::= { WITH SYNTAX SupportedAlgorithm EQUALITY MATCHING RULE algorithmIdentifierMatch ID id-at-supportedAlgorithms } SupportedAlgorithm ::= SEQUENCE { algorithmIdentifier AlgorithmIdentifier, intendedUsage [0] KeyUsage OPTIONAL, intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL } Each value of the multi-valued attribute shall have a distinct algorithmIdentifier value. The value of the intendedUsage component provides an indication of the intended usage of the algorithm (see 12.2.2.3 for recognized uses). The value of the intendedCertificatePolicies component identifies the certificate policies and, optionally, certificate policy qualifiers with which the identified algorithm may be used. From owner-ietf-smime@imc.org Mon Oct 11 16:27:48 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14421 for ; Mon, 11 Oct 1999 16:27:47 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id MAA09187 for ietf-smime-bks; Mon, 11 Oct 1999 12:44:47 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09183 for ; Mon, 11 Oct 1999 12:44:46 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HHB>; Mon, 11 Oct 1999 12:45:59 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Walter Williams'" , Russ Housley Cc: wpolk@nist.gov, ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:46:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if -----Original Message----- From: Walter Williams [mailto:walter.williams@gte.com] Sent: Sunday, September 12, 1999 7:30 PM To: Russ Housley; jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Russ, One thought here is backwards compatability of existing s/mime aware clients. Some may have been written to check for the cert in only one of the available attributes. You don't want to change the directory in a way which prevents an older client from seeing the certificate. (might though give vendors a thrill to have to say: so sorry, but due to a standard change we must force you to upgrade to support s/mime again) Certificates are also not very large (compaired with a .jpg picture of the directory entrant as a comparitive example) and so the data bloat does not waste much drive space. Of course, if all available clients look in both places, my statement is pretty much a waste of good bandwidth. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Russ Housley Sent: Sunday, September 12, 1999 12:35 PM To: jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Jim: I must agree with many of the points that Dave Kemp made. Is it worth putting multiple copies of the same certificate into the Directory? This can lean to inconsistincies. Maybe it would be better to follow the PKIX LDAP Schema and add an S/MIME-specific attribute too the directory entry. The binding you seek could be achieved by putting a reference to a specific certificate that is available in the userCertificate attribute inside the S/MIME-specific attribute. Thoughts? Russ From owner-ietf-smime@imc.org Thu Oct 14 17:52:11 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14458 for ; Thu, 14 Oct 1999 17:52:10 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id OAA27924 for ietf-smime-bks; Thu, 14 Oct 1999 14:09:42 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA27917 for ; Thu, 14 Oct 1999 14:09:41 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA26723 for ; Thu, 14 Oct 1999 14:03:55 -0700 (PDT) Message-Id: <4.2.0.58.19991014164821.00a018d0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 14 Oct 1999 16:51:15 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you want to have a time slot on the agenda in DC, please drop me an note today. Russ From owner-ietf-smime@imc.org Wed Oct 20 07:43:00 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25775 for ; Wed, 20 Oct 1999 07:42:59 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id DAA07280 for ietf-smime-bks; Wed, 20 Oct 1999 03:55:45 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA07276 for ; Wed, 20 Oct 1999 03:55:44 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24384; Wed, 20 Oct 1999 06:58:16 -0400 (EDT) Message-Id: <199910201058.GAA24384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-03.txt Date: Wed, 20 Oct 1999 06:58:16 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-03.txt Pages : 8 Date : 19-Oct-99 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely - for example when two domains use incompatible messaging technologies such as X.400 and SMTP/MIME. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019140149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019140149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Fri Oct 22 07:25:45 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06972 for ; Fri, 22 Oct 1999 07:25:44 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id DAA20333 for ietf-smime-bks; Fri, 22 Oct 1999 03:56:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA20326 for ; Fri, 22 Oct 1999 03:56:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06172; Fri, 22 Oct 1999 06:59:11 -0400 (EDT) Message-Id: <199910221059.GAA06172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-certdist-04.txt Date: Fri, 22 Oct 1999 06:59:11 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Certificate Distribution Specification Author(s) : J. Schaad Filename : draft-ietf-smime-certdist-04.txt Pages : 20 Date : 21-Oct-99 Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-certdist-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-certdist-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991021143006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-certdist-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-certdist-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021143006.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Fri Oct 22 12:54:57 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23955 for ; Fri, 22 Oct 1999 12:54:57 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id JAA15261 for ietf-smime-bks; Fri, 22 Oct 1999 09:09:13 -0700 (PDT) Received: from cnuproxy. (cnuproxy.cnu.edu.cn [202.204.208.13]) by mail.imc.org (8.9.3/8.9.3) with SMTP id JAA15246; Fri, 22 Oct 1999 09:09:06 -0700 (PDT) From: searchers@freeola.com Received: from 202.204.208.13 by cnuproxy. (SMI-8.6/SMI-SVR4) id AAA06205; Sat, 23 Oct 1999 00:08:36 +0800 Message-Id: <199910221608.AAA06205@cnuproxy.> To: Friend@public.com Date: Fri, 22 Oct 99 14:31:36 EST Subject: Your Web Page Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Increase your Web Site visiblity ! Try out : *** Proven Web Page Optimisation Software *** >> Audited results 55% Number 1 90% top 5 << *** Macro Media Web Page Design Software **** >>> Make your Web Pages sparkle <<<< **** Accept checks from your Web Site ***** >>>> Improve your margins & Cashflow <<<< Go to : http://www.pcpages.com/bizzinews/ ++++ Sender & Remove Instructions ++++ Free Business Links Bevere Close Worcester Tel 121 643 2448 Email : searchers@freeola.com ++++++++++++++++++++++++++++++++++++ From owner-ietf-smime@imc.org Fri Oct 22 17:44:36 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09082 for ; Fri, 22 Oct 1999 17:44:35 -0400 (EDT) Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id OAA06816 for ietf-smime-bks; Fri, 22 Oct 1999 14:01:49 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA06809 for ; Fri, 22 Oct 1999 14:01:47 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA25494 for ; Fri, 22 Oct 1999 13:56:18 -0700 (PDT) Message-Id: <4.2.0.58.19991022153652.00a31a90@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 15:37:45 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Proposed Charter Update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please review and comment. Russ = = = = = = = = = = = S/MIME Mail Security (smime) Chair: Russ Housley Security Area Director: Jeffrey Schiller Marcus Leech Mailing Lists: General Discussion: ietf-smime@imc.org To Subscribe: ietf-smime-request@imc.org Archive: http://www.imc.org/ietf-smime/ Description of Working Group: The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications. The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks. The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of "mandatory to implement" algorithms may be selected. To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document. Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined. In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. Compressing data before encrypting it or signing it has a number of advantages. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compressed will provide all of these advantages. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent. S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large organizations will be used as examples. S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate. The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap. Goals and Milestones: History: First draft of small subgroup attack avoidance. First draft of certificate distribution specification. First draft of domain security services document. First draft of CMS and ESS examples document. First draft of KEA and SKIPJACK algorithm specification. First draft of IDEA algorithm specification. First draft of CMS RecipientInfo extension. First draft of CAST algorithm specification. October 1999: First draft of security label usage specification. First draft of elliptic curve algorithm specification. First draft of CMS compressed data content type specification. Last call on certificate distribution specification. November 1999: First draft of mail list key distribution. Updated draft of domain security services document. Last call on CAST algorithm specification. Last call on small subgroup attack avoidance. Last call on KEA and SKIPJACK algorithm specification. Submit small subgroup attack avoidance as Informational RFC. Submit KEA and SKIPJACK algorithm specification as Informational RFC. December 1999: Last call on CMS and ESS examples document. Last call on IDEA algorithm specification. Last call on CMS RecipientInfo extension. January 2000: Last call on security label usage specification. Last call on mail list key distribution. Last call on CMS compressed data content type specification. Submit certificate distribution specification as a Proposed Standard. February 2000: Last call on elliptic curve algorithm specification. Submit CAST algorithm specification as Informational RFC. March 2000: Submit CMS and ESS examples document as Informational RFC. Submit IDEA algorithm specification as Informational RFC. Submit CMS RecipientInfo extension as a Proposed Standard. Submit mail list key distribution as a Proposed Standard. April 2000: Submit CMS compressed data content type specification as a Proposed Standard. May 2000: Submit elliptic curve algorithm specification as a Proposed Standard. Submit security label usage specification as Informational RFC. July 2000: Last call on domain security services document. September 2000: Submit domain security services as Experimental RFC. From owner-ietf-smime@imc.org Fri Oct 22 17:53:49 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09420 for ; Fri, 22 Oct 1999 17:53:48 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id OAA09544 for ietf-smime-bks; Fri, 22 Oct 1999 14:23:59 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA09533; Fri, 22 Oct 1999 14:23:56 -0700 (PDT) Message-Id: <4.2.1.19991022142649.00be0680@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 22 Oct 1999 14:27:52 -0700 To: Russ Housley , ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Proposed Charter Update In-Reply-To: <4.2.0.58.19991022153652.00a31a90@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >December 1999: > Last call on CMS and ESS examples document. We've had a slow start on the examples draft (but are now moving ahead; -03 was turned in yesterday). I'd move this to February 2000 to be realistic. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Fri Oct 22 18:05:57 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10027 for ; Fri, 22 Oct 1999 18:05:57 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id OAA10307 for ietf-smime-bks; Fri, 22 Oct 1999 14:28:50 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA10303 for ; Fri, 22 Oct 1999 14:28:49 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA26155 for ; Fri, 22 Oct 1999 14:23:24 -0700 (PDT) Message-Id: <4.2.0.58.19991022172442.00a20840@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 17:27:54 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Working Group Last Call:draft-ietf-smime-certdist-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Announcing S/MIME Working Group Last Call. Title : Certificate Distribution Specification Author(s) : J. Schaad Filename : draft-ietf-smime-certdist-04.txt Pages : 20 Date : 21-Oct-99 Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. Working Group Last Call will close after the IETF meeting. It will close on 14 November. S/MIME WG Chair, Russ From owner-ietf-smime@imc.org Mon Oct 25 06:08:21 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02127 for ; Mon, 25 Oct 1999 06:08:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA02212 for ietf-smime-bks; Mon, 25 Oct 1999 02:32:58 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02188 for ; Mon, 25 Oct 1999 02:31:26 -0700 (PDT) Received: from localhost (kris@localhost) by cmcltd.com (8.8.7/8.8.7) with ESMTP id PAA10601 for ; Mon, 25 Oct 1999 15:56:24 +0530 Date: Mon, 25 Oct 1999 15:56:24 +0530 (IST) From: V KRISHNA REDDY To: ietf-smime@imc.org Subject: S-MIME key length Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I want the information whether s-mime specification gives us the flexibilty to use 1024 bit key length.Actually what is the status of the specification regarding key length. --krishna From owner-ietf-smime@imc.org Mon Oct 25 07:27:07 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04420 for ; Mon, 25 Oct 1999 07:27:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA05443 for ietf-smime-bks; Mon, 25 Oct 1999 03:58:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05439 for ; Mon, 25 Oct 1999 03:58:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03544; Mon, 25 Oct 1999 07:01:46 -0400 (EDT) Message-Id: <199910251101.HAA03544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-03.txt Date: Mon, 25 Oct 1999 07:01:46 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-03.txt Pages : 8 Date : 22-Oct-99 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022140310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022140310.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Mon Oct 25 10:34:24 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12043 for ; Mon, 25 Oct 1999 10:34:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA09065 for ietf-smime-bks; Mon, 25 Oct 1999 06:52:06 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09061 for ; Mon, 25 Oct 1999 06:52:05 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA17051; Mon, 25 Oct 1999 09:55:28 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA17047; Mon, 25 Oct 1999 09:55:28 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA22918; Mon, 25 Oct 1999 09:54:43 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA04603; Mon, 25 Oct 1999 09:51:19 -0400 (EDT) Message-Id: <199910251351.JAA04603@ara.missi.ncsc.mil> Date: Mon, 25 Oct 1999 09:51:18 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org, housley@spyrus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4DrYVkrB/I/zpO9rzRN9hg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Certdist draft 4 is an improvement over draft 3, in that it allows CAs (not just End Entities) to sign the SMimeCertificatePublish object and it allows End Entity certificates to be published in the userCertificate attribute in lieu of the proposed userSmimeCertificate attribute. However, it is still not clear what certificate publishing problem certdist is trying to solve. Section 2 says: "LDAP currently has the userCertificate property [attribute? -- dpk] defined for just that purpose. ... While some directories, such as X.500 directories, provide for a directory entry to contain the CA certificate, this is not the case for all directories." Since LDAP directories have both user and CA certificate attributes, and LDAP is the Internet mechanism of choice for publishing and retrieving certificates, it would seem that a draft which proposes an alternative cert publishing mechanism as an Internet Standard would have a high burden of proof to justify the duplication. The IESG is relatively strict in discouraging the definition of overlapping mechanisms. The draft should cite at least one example of an Internet directory which: 1) is used to distribute certificates, 2) could be modified to include the proposed userSmimeCertificate attribute, and 3) could not be modified to contain the standard caCertificate attribute. If such a directory exists, and needs to be accommodated in an Internet Standard, I propose that the following be added to section 4.3, which subsumes the LDAP-specific wording currently in section 4.5: 4.3 CertificateSet If the SMimeCertificatePublish object is published in the LDAP userSmimeCertificate attribute, the SignedData->certificates field of the object MUST be absent. If the SMimeCertificatePublish object is distributed by other means, this draft imposes additional restrictions ... This would ensure that LDAP directories only have to store one copy of user and CA certificates in the standard user- and CA-certificate attributes, instead of duplicating user certificates in two attributes and maintaining duplicate copies of CA certificates for every user. In LDAP directories, userSmimeCertificate would thus contain only the signed attributes; the eContent and CertificateSet fields would be empty. Dave Kemp > Announcing S/MIME Working Group Last Call. > > Title : Certificate Distribution Specification > Author(s) : J. Schaad > Filename : draft-ietf-smime-certdist-04.txt > Pages : 20 > Date : 21-Oct-99 > > Current methods of publishing certificates in directory services are > restricted to just certificates. This document provides a method of > publishing certificates with secondary support information such as > the SMimeCapabilities attribute (containing bulk algorithm support) > in a way that is both authenticated and bound to a given > certificate. > > Working Group Last Call will close after the IETF meeting. It will close > on 14 November. > > S/MIME WG Chair, > Russ From owner-ietf-smime@imc.org Mon Oct 25 14:46:41 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01686 for ; Mon, 25 Oct 1999 14:46:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11324 for ietf-smime-bks; Mon, 25 Oct 1999 09:06:02 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11320 for ; Mon, 25 Oct 1999 09:06:01 -0700 (PDT) Message-Id: <4.2.1.19991025090453.00bcbaa0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 09:09:17 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt In-Reply-To: <199910251351.JAA04603@ara.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Tue Oct 26 11:21:47 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09820 for ; Tue, 26 Oct 1999 11:21:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27735 for ietf-smime-bks; Tue, 26 Oct 1999 07:38:47 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27730; Tue, 26 Oct 1999 07:38:46 -0700 (PDT) Received: from ibm (A200-35.PPP.FTWO.TX.VERIO.NET [206.50.209.35]) by mailhost.onramp.net (8.9.3/8.9.3) with SMTP id JAA29643; Tue, 26 Oct 1999 09:41:48 -0500 (CDT) From: "Rik Drummond" To: "Paul Hoffman / IMC" , Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt Date: Tue, 26 Oct 1999 09:40:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.2.1.19991025090453.00bcbaa0@mail.imc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Paul... Rik -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Paul Hoffman / IMC Sent: Monday, October 25, 1999 11:09 AM To: ietf-smime@imc.org Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Tue Oct 26 13:21:29 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15095 for ; Tue, 26 Oct 1999 13:21:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00217 for ietf-smime-bks; Tue, 26 Oct 1999 09:19:17 -0700 (PDT) Received: from citicorp.com (mango1.citicorp.com [192.193.195.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00210; Tue, 26 Oct 1999 09:19:03 -0700 (PDT) From: bartley.o'malley@citicorp.com Received: from myrtle2.citicorp.com (imta.citicorp.com [192.193.196.189]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id MAA17169; Tue, 26 Oct 1999 12:18:38 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (omroute4.email.citicorp.com [163.39.141.205]) by myrtle2.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21750; Tue, 26 Oct 1999 12:21:12 -0400 (EDT) Received: from mercury.lew.gb.citicorp.com (root@mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA07923; Tue, 26 Oct 1999 12:19:51 -0400 (EDT) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id RAA17649; Tue, 26 Oct 1999 17:16:50 +0100 (BST) X-OpenMail-Hops: 1 Date: Tue, 26 Oct 1999 17:16:40 +0100 Message-Id: Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt MIME-Version: 1.0 TO: ietf-smime@imc.org, phoffman@imc.org Content-Type: multipart/mixed; boundary="openmail-part-0c282f9e-00000001" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --openmail-part-0c282f9e-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Monday, October 25, 1999 5:09 PM To: ietf-smime Cc: phoffman Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. [O'Malley, Bartley] Is this sufficient grounds to junk it? If it is not widely implemented yet because of inherent problems, then fine, but if it is simply due to its newness(my vote) we risk delaying the implementation of either by muddying the water with the introduction of a second. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. [O'Malley, Bartley] Pause for a moment... Do you really?(wish that is) If you did, why would you support the introduction of an overlapping standard. --Paul Hoffman, Director --Internet Mail Consortium --openmail-part-0c282f9e-00000001 Content-Type: application/ms-tnef; name="WINMAIL.DAT" Content-Disposition: attachment; filename="WINMAIL.DAT" Content-Transfer-Encoding: base64 eJ8+ItxFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAD0AAABSRTogV29ya2luZyBHcm91cCBM YXN0IENhbGw6ZHJhZnQtaWV0Zi1zbWltZS1jZXJ0ZGlzdC0wNC50eHQAZRUBA5AGABAAAAAB AAAAQAA5AED+VWPNH78BHAQBA5AGABQAAAABAAAAHgBCEAEAAAABAAAAAAAAAHMAAQOQBgAo AAAAAQAAAAIBcQABAAAAFgAAAAG/H81jAEObNe+LhhHTsJoAAfrU+5YAADwLAQOQBgBQAAAA AQAAAB4AcAABAAAAPQAAAFJFOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDpkcmFmdC1pZXRm LXNtaW1lLWNlcnRkaXN0LTA0LnR4dAAAAAAyFgEDkAYAQAAAAAEAAAACATEAAQAAAC0AAAA0 LjIuMS4xOTk5MTAyNTA5MDQ1My4wMGJjYmFhMChhKW1haWwuaW1jLm9yZwAAAAA2DAEDkAYA DAAAAAEAAAALAAIAAQAAAA8AAQOQBgAMAAAAAQAAAAMALgAAAAAAMgABA5AGABgAAAABAAAA HgA9AAEAAAAFAAAAUkU6IAAAAABTAQEDkAYALAAAAAEAAAAeAIsDCCAGAAAAAADAAAAAAAAA RgAAAAA4hQAAAQAAAAEAAAAAAAAAoAIBA5AGACwAAAABAAAAHgCMAwggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAKACAQOQBgAsAAAAAQAAAB4AjQMIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAACgAgEDkAYAJAAAAAEAAAADAI4DCCAGAAAAAADAAAAA AAAARgAAAAAYhQAAAAAAAGYCAQOQBgAkAAAAAQAAAAMAjwMIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAYAIBA5AGACQAAAABAAAAAwCQAwggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AABgAgEDkAYAJAAAAAEAAAALAJEDCCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAGcCAQOQ BgAkAAAAAQAAAAMAkgMIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAUwIBA5AGADAAAAAB AAAAHgCTAwggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAAAACSAwEDkAYA JAAAAAEAAAADAJQDCCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAK4DAQOQBgAgAAAAAQAA AAIBCzABAAAAEAAAAO41m0OGi9MRsJoAAfrU+5bwCAEDkAYADAAAAAEAAAADAIAQ/////5AE AQkABAACAAAAAAAAAAEDkAYADAAAAAEAAAALACMAAAAAAC8AAQOQBgAMAAAAAQAAAAsAKQAA AAAANQABBJAGALADAAACAAAAEgAAAB4AATABAAAACwAAACdwaG9mZm1hbicAAAIB/w8BAAAA NwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHBob2ZmbWFuAFNNVFAAcGhvZmZtYW5AaW1j Lm9yZwAAAwAVDAEAAAADAAAwAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAaDAEAAAATAAAA TydNYWxsZXksIEJhcnRsZXkAAAACARkMAQAAAD8AAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEA AAALAAAAAAAAADEdTydNYWxsZXkeMh1CYXJ0bGV5HjUdNjBFVUxPTgAAHgADMAEAAAARAAAA cGhvZmZtYW5AaW1jLm9yZwAAAAACAQswAQAAABYAAABTTVRQOlBIT0ZGTUFOQElNQy5PUkcA AAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAAJAAAAcGhvZmZtYW4AAAAAAgH3XwEAAAA3AAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcGhvZmZtYW4AU01UUABwaG9mZm1hbkBpbWMub3Jn AAALAA8OAAAEgAMA/g8GAAAAAwAAOQAAAAALAEA6AQASAAMAcToAAAAAEwAAAB4AATABAAAA DQAAACdpZXRmLXNtaW1lJwAAAAACAf8PAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAA AABpZXRmLXNtaW1lAFNNVFAAaWV0Zi1zbWltZUBpbWMub3JnAAADABUMAQAAAAMAADABAAAA HgACMAEAAAAFAAAAU01UUAAAAAAeABoMAQAAABMAAABPJ01hbGxleSwgQmFydGxleQAAAAIB GQwBAAAAPwAAAAAAAACNVUzQ7DwRzoH/CAAJsQN6AQAAAAsAAAAAAAAAMR1PJ01hbGxleR4y HUJhcnRsZXkeNR02MEVVTE9OAAAeAAMwAQAAABMAAABpZXRmLXNtaW1lQGltYy5vcmcAAAIB CzABAAAAGAAAAFNNVFA6SUVURi1TTUlNRUBJTUMuT1JHAAMA/18AAAAAAwD9XwEAAAAeAPZf AQAAAAsAAABpZXRmLXNtaW1lAAACAfdfAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAA AABpZXRmLXNtaW1lAFNNVFAAaWV0Zi1zbWltZUBpbWMub3JnAAACAfYPAQAAAAQAAAAAAAAB CwAPDgAABIADAP4PBgAAAAMAADkAAAAACwBAOgEAAAADAHE6AAAAAB60 --openmail-part-0c282f9e-00000001-- From owner-ietf-smime@imc.org Tue Oct 26 16:56:08 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26717 for ; Tue, 26 Oct 1999 16:56:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA04752 for ietf-smime-bks; Tue, 26 Oct 1999 13:15:23 -0700 (PDT) Received: from barbar.esat.kuleuven.ac.be (root@barbar.esat.kuleuven.ac.be [134.58.56.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04738 for ; Tue, 26 Oct 1999 13:15:20 -0700 (PDT) Received: from bronx (bronx.esat.kuleuven.ac.be [134.58.189.79]) by barbar (version 8.8.5) with ESMTP id WAA14448; Tue, 26 Oct 1999 22:18:24 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Date: Tue, 26 Oct 1999 22:18:24 +0200 (CEST) From: Eurocrypt 2000 X-Sender: ec2000@bronx To: ietf-smime@imc.org Subject: Eurocrypt 2000 submission deadline: November 3, 1999 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------------------------------------------------------------- E U R O C R Y P T 2 0 0 0 May 14-18, 2000 Bruges (Brugge), Belgium http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ ------------------------------------------------------------- This is a reminder that the submission deadline for Eurocrypt 2000 is November 3, 1999. Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ for more information. ------------------------------------------------------------- From owner-ietf-smime@imc.org Tue Oct 26 20:04:08 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06626 for ; Tue, 26 Oct 1999 20:04:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA08052 for ietf-smime-bks; Tue, 26 Oct 1999 16:14:06 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08048 for ; Tue, 26 Oct 1999 16:14:05 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910262314.QAA08048@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 1999 17:16:03 -0600 Mime-Version: 1.0 Date: Tue, 26 Oct 1999 17:15:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m"; modification-date="Tue, 26 Oct 1999 17:15:56 -0600" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: base64 MIIp4QYJKoZIhvcNAQcCoIIp0jCCKc4CAQExCzAJBgUrDgMCGgUAMIIeHAYJKoZIhvcNAQcBoIIe DQSCHglGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUkU6IFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsOmRyYWZ0LWlldGYtc21pbWUtY2VydGRpc3QtMDQudHh0DQpUbzogaWV0Zi1z bWltZUBpbWMub3JnDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9Il9f X19LWkZPSU1QTUZPTURXRkxYV1dLWV9fX18iDQoNCg0KLS1fX19fS1pGT0lNUE1GT01EV0ZMWFdX S1lfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9aXNvLTg4NTktMQ0KQ29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQpJJ20gYWZyYWlkIEkg c3Ryb25nbHkgZGlzYWdyZWUgd2l0aCBQYXVsIGFuZCBSaWssIGFuZD0yMA0KYWdyZWUgd2l0aCBC YXJ0bGV0dCBhbmQgRGF2aWQgS2VtcCBpbnN0ZWFkLg0KDQpJJ20gc3BlYWtpbmcgYXMgYW4gYXJj aGl0ZWN0IHdobyBpcyByZXNwb25zaWJsZSBmb3IgZGVmaW5pbmcgb3VyDQpmdXR1cmUgZGlyZWN0 aW9uIHdpdGggcmVzcGVjdCB0byBvdXIgR3JvdXBXaXNlIFMvTUlNRSBWMw0KaW1wbGVtZW50YXRp b24sIGluIGFkZGl0aW9uIHRvIG91ciBQS0kgcHJvZHVjdCBsaW5lLCBpbmNsdWRpbmc9MjANCnRo ZSBOb3ZlbGwgQ2VydGlmaWNhdGUgU2VydmVyIDIuMCAod2hpY2ggd2FzIHJlbGVhc2VkIGp1c3QN CmhvdXJzIGFnbyAgYXMgYSBGUkVFIHdlYiByZWxlYXNlICAtLSBzZWU9MjANCmh0dHA6Ly93d3cu bm92ZWxsLmNvbS9wcmVzcy9hcmNoaXZlLzE5OTkvMTAvcHI5OTEzMC5odG1sKSw9MjANCmFzIHdl bGwgYXMgb3VyIExEQVAgZGlyZWN0aW9uIGluIHRoaXMgc3BhY2UuDQoNCkkgYmVsaWV2ZSB0aGF0 IHByb3ZpZGluZyBtdWx0aXBsZSAic3RhbmRhcmQiIHdheXMgb2YgZG9pbmc9MjANCnNvbWV0aGlu ZyB0aGF0IGlzIHJlbGF0aXZlbHkgc2ltcGxlIGluZXZpdGFibHkgbGVhZHMgdG89MjANCnVubmVj ZXNzYXJ5IGR1cGxpY2F0aW9uIG9mIGVmZm9ydCwgYW5kIG1vcmUgaW1wb3J0YW50bHksDQpzZXJp b3VzIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgYmV0d2VlbiB2ZW5kb3JzLg0KDQpJdCdzIGRp ZmZpY3VsdCBlbm91Z2ggdG8gZ2V0IG11bHRpcGxlIHZlbmRvcnMgdG8gZG8gc29tZXRoaW5nDQpy aWdodCB3aGVuIHRoZXJlIGlzIG9ubHkgb25lIHdheSB0byBkbyBpdC4gSWYgdGhlcmUgYXJlIG11 bHRpcGxlDQpvcHRpb25zLCBhcyB3aXRoIHRoZSBjdXJyZW50IGxvZ2ljIGZvciBkZXRlcm1pbmlu ZyB3aGF0IGVuY3J5cHRpb24NCmFsZ29yaXRobSB0byB1c2UsIHNvbWVvbmUgaXMgYm91bmQgdG8g c2NyZXcgaXQgdXAsIHdpdGggdGhlDQpyZXN1bHQgdGhhdCB0d28gZGlmZmVyZW50IHByb2R1Y3Rz IGhhdmUgZGlmZmljdWx0eSBjb21tdW5pY2F0aW5nLg0KDQpJZiBJIGNvdWxkIHR1cm4gdGhlIGNs b2NrIGJhY2sgYSB5ZWFyIG9yIHR3bywgSSB3b3VsZCBoYXZlIHByZWZlcnJlZD0yMA0KdGhhdCB0 aGUgU01JTUUgQ2FwYWJpbGl0aWVzIGF0dHJpYnV0ZSBiZSBpbmNsdWRlZCBpbiB0aGUgZW5kLXVz ZXIncw0KY2VydGlmaWNhdGUgZGlyZWN0bHkuDQoNCkZhaWxpbmcgdGhhdCwgSSB3b3VsZCBoYXZl IGxpa2VkIHRvIHNlZSBhICJDYXBhYmlsaXRpZXMiIGNlcnRpZmljYXRlID0NCnRoYXQ9MjANCmlz IGlzc3VlZCBhbmQgc2lnbmVkIGJ5IHRoZSBlbmQtdXNlciBoZXJzZWxmLCB0aGF0IGluIGFkZGl0 aW9uIHRvID0NCmNvbnRhaW5pbmcNClNNSU1FIHN0dWZmIHJlZ2FyZGluZyB3aGF0IGFsZ29yaXRo bXMgd2VyZSBzdXBwb3J0ZWQsIG1pZ2h0DQphbHNvIGhhdmUgY29udGFpbmVkIHRoZSBlcXVpdmFs ZW50IG9mIGEgQ1BTIHN0YXRlbWVudCB0aGF0IGRlZmVuZHM9MjANCnRoZSB1c2VyLCBhbmQgbm90 IGp1c3QgdGhlIENBLCBmcm9tIHVud2FudGVkIHJlbGlhbmNlIG9uIGEgc2lnbmF0dXJlLCBmb3IN CmV4YW1wbGUuICBJZiB0aGUgZW5kLXVzZXIgcHVibGlzaGVkIHN1Y2ggYSBjZXJ0aWZpY2F0ZSwg aXQgd291bGQgaGF2ZSA9DQptYWRlPTIwDQpzZW5zZSB0byBwdXQgaXQgaW4gdGhlIHNhbWUgTERB UCBidWNrZXQgYXMgdGhlIGVuZC11c2VyJ3Mgb3duIGNlcnRpZmljYXRlLg0KDQpCb3RoIG9mIHRo b3NlIG9wdGlvbnMgYXJlIHByb2JhYmx5IGZvcmVjbG9zZWQgYnkgbm93LCB1bmZvcnR1bmF0ZWx5 LA0Kc28gd2UgYXJlIGxlZnQgd2l0aCB0aGUgcHJvYmxlbSBvZiB3aGVyZSB0byBwdXQgdGhlIFNN SU1FIENhcGFiaWxpdGllcywgPQ0KYW5kDQp3aGVyZSB0byBwdXQgdGhlIHVzZXIncyBTL01JTUUg Y2VydGlmaWNhdGVzLg0KDQpXaXRoIHJlc3BlY3QgdG8gdGhlIGNlcnRpZmljYXRlcyB0aGVtc2Vs dmVzLCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueT0yMA0KcXVlc3Rpb24gYXQgYWxsIC0tIGFs bCwgb3IgbmVhcmx5IGFsbCwgb2YgdGhlIHB1YmxpYyBDQXMgYW5kIENBIHRvb2xraXQgPQ0KdmVu ZG9ycz0yMA0KcHVibGlzaCB0aGUgY2VydGlmaWNhdGVzIGluIHRoZSBhbHJlYWR5IGRlZmluZWQg TERBUCBhdHRyaWJ1dGVzLg0KDQpBbmQgZnJvbSBhIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQgcGVy c3BlY3RpdmUsIHRoZSBsYXN0IHRoaW5nIHRoYXQgZWl0aGVyID0NCnRoZQ0KdXNlci9zeXN0ZW0g YWRtaW5pc3RyYXRvciBvciB0aGUgdmVuZG9yIHdhbnRzIGlzIHRvIGhhdmUgdG8gbWFuYWdlIFRX Tz0yMA0Kc2V0cyBvZiBjZXJ0aWZpY2F0ZXMgc3RvcmVkIGluIHNlcGFyYXRlIHBsYWNlcy4gVGhl IHBvc3NpYmlsaXRpZXMgZm9yID0NCmVycm9ycw0KYXJlIG9idmlvdXMgLS0gb25lIGNlcnRpZmlj YXRlIGdldHMgZGVsZXRlZC9yZXBsYWNlLCBhbmQgdGhlIG90aGVyIG9uZT0yMA0KZG9lc24ndCwg ZXRjLg0KDQpJIHN1cHBvc2UgdGhhdCBpdCBjb3VsZCBiZSBhcmd1ZWQgZnJvbSBhbiBMREFQIHVz ZXIncyBwZXJzcGVjdGl2ZSB0aGF0PTIwDQppdCBtaWdodCBiZSBjb252ZW5pZW50IHRvIGJlIGFi bGUgdG8gYnJvd3NlIHRocm91Z2ggYSBkaXJlY3RvcnksIGZpbmQgdGhlDQpkZXNpcmVkIHVzZXIs IGFuZCBjbGljayBvbiBvbmUgZGlyZWN0b3J5IGF0dHJpYnV0ZSB0byByZXRyaWV2ZSB0aGUgPQ0K U01JTUU9MjANCkNhcGFiaWxpdGllcyBhbmQgdGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBjaGFpbiBp biBvbmUgb3BlcmF0aW9uLiAgSSdtID0NCnJlbGF0aXZlbHkNCmNlcnRhaW4gdGhhdCdzIHRoZSBz Y2VuYXJpbyB0aGF0IHRoZSBhdXRob3JzIGhhZCBpbiBtaW5kIGZvciB0aGlzID0NCmNhcGFiaWxp dHkuDQoNCkhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHdoYXQgd2lsbCBoYXBwZW4gaW4g cHJhY3RpY2UuDQoNCkluc3RlYWQsIEkgZXhwZWN0IHRoYXQgYW4gZS1tYWlsIHVzZXIgd2lsbCB0 eXBlIGluIG9yIHNlbGVjdCBuYW1lcyBmcm9tPTIwDQpoaXMgcGVyc29uYWwgb3Igc3lzdGVtIGFk ZHJlc3MgYm9vay4gVGhlbiBoZSBvciBzaGUgd2lsbCBkZWNpZGUgdG89MjANCmVuY3J5cHQgdGhl IG1lc3NhZ2UsIHdpdGhvdXQgcmVnYXJkIHRvIHdoZXRoZXIgb3Igbm90IGFsbCBvZiB0aGUgY2Vy dGlmaWNhdD0NCmVzPTIwDQpmb3IgYWxsIG9mIHRoZSBhZGRyZXNzZWVzIGhhdmUgYWxyZWFkeSBi ZWVuIGNhY2hlZCBsb2NhbGx5Lg0KDQpBdCB0aGF0IHBvaW50LCB0aGUgTVVBIHNob3VsZCBhdXRv bWF0aWNhbGx5IGZldGNoIHRoZSBjZXJ0aWZpY2F0ZXMgYW5kPTIwDQpTTUlNRSBjYXBhYmlsaXRp ZXMgZm9yIGFsbCBvZiB0aGUgdXNlcnMsIGFuZCBwZXJoYXBzIHByb21wdCB0aGUgdXNlcj0yMA0K dG8gbWFrZSBzdXJlIHRoYXQgdGhvc2UgYXJlIGluIGZhY3QgdGhlIHJpZ2h0IGNlcnRpZmljYXRl cyBmb3IgdGhvc2UgPQ0KdXNlcnMuDQoNCkJ1dCB0aGUgbWFuYWdlbWVudCBvZiB0aGUgY2VydGlm aWNhdGUgY2hhaW4sIHRoZSBTTUlNRSBDYXBhYmlsaXRpZXMsID0NCmFuZD0yMA0KYW55IG90aGVy ICJwbHVtYmluZyIgdGhhdCB0aGUgdXNlciBkb2Vzbid0IGFic29sdXRlbHkgaGF2ZSB0byBiZSBl eHBvc2VkID0NCnRvPTIwDQpzaG91bGQgYmUgaGFuZGxlZCBieSB0aGUgTVVBLiAgU28gdGhlIHJl dHJpZXZhbCBvZiB0aGUgZW5kLXVzZXJzIGNlcnRpZmljYXQ9DQplKHMpLD0yMA0KdGhlIENBIGNl cnRpZmljYXRlcywgYW5kIHRoZSBTTUlNRSBDYXBhYmlsaXRpZXMgc2hvdWxkIGFsbCBiZSBoYW5k bGVkPTIwDQphdXRvbWF0aWNhbGx5LCB3aXRob3V0IHVzZXIgaW50ZXJ2ZW50aW9uLiBTaW5jZSBp dCBpcyBzb2Z0d2FyZSB0aGF0IGlzID0NCmdvaW5nPTIwDQp0byBiZSBkb2luZyB0aGUgcmV0cmll dmFsLCBhbmQgbm90IGEgaHVtYW4gdXNlciwgcmV0cmlldmluZyBmcm9tIG11bHRpcGxlID0NCmF0 dHJpYnV0ZXMNCmlzIG5vdCBhIHByb2JsZW0uDQoNCkZyb20gdGhpcyBwZXJzcGVjdGl2ZSwgSSB0 aGluayBpdCBpcyBvYnZpb3VzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSBhbmQgPQ0Kb25seQ0K d2F5IHRvIHN0b3JlIGFuZCByZXRyaWV2ZSBzdWNoIGNlcnRpZmljYXRlcy4gT3RoZXJ3aXNlLCBp dCB3aWxsIGJlID0NCm5lY2Vzc2FyeT0yMA0KdG8gaW1wbGVtZW50IGJvdGggdHlwZXMgb2YgZGly ZWN0b3J5IGZldGNoZXMsIGp1c3QgaW4gY2FzZSwgYW5kIHRoYXQganVzdA0KY2F1c2VzIG1vcmUg Y29tcGxleGl0eSwgY29kZSBibG9hdCwgc3lzdGVtIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Rp bmcsID0NCmV0Yy4NCll1Y2shDQoNClRoZSBjdXJyZW50IHdheSBvZiByZXRyaWV2aW5nIGNlcnRp ZmljYXRlcyBpcyBjb21wbGV0ZWx5IGFkZXF1YXRlLCBJTUhPLg0KSWYgaXQgYWluJ3QgYnJva2Us IGRvbid0IGZpeCBpdC4NCg0KQm9iDQoNCg0KPj4+IDxiYXJ0bGV5Lm8nbWFsbGV5QGNpdGljb3Jw LmNvbT4gMTAvMjYvOTkgMTA6MTZBTSA+Pj4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogcGhvZmZtYW4gW1NNVFA6cGhvZmZtYW5AaW1jLm9yZ109MjANClNlbnQ6IE1vbmRh eSwgT2N0b2JlciAyNSwgMTk5OSA1OjA5IFBNDQpUbzogaWV0Zi1zbWltZQ0KQ2M6IHBob2ZmbWFu DQpTdWJqZWN0OiBSZTogV29ya2luZyBHcm91cCBMYXN0IENhbGw6ZHJhZnQtaWV0Zi1zbWltZS1j ZXJ0ZGlzdC0wNC50eHQNCg0KQXQgMDk6NTEgQU0gMTAvMjUvOTkgLTA0MDAsIERhdmlkIFAuIEtl bXAgd3JvdGU6DQo+U2luY2UgTERBUCBkaXJlY3RvcmllcyBoYXZlIGJvdGggdXNlciBhbmQgQ0Eg Y2VydGlmaWNhdGUgYXR0cmlidXRlcywNCg0KQWdyZWUuDQoNCj5hbmQgTERBUCBpcyB0aGUgSW50 ZXJuZXQgbWVjaGFuaXNtIG9mIGNob2ljZSBmb3IgcHVibGlzaGluZyBhbmQgcmV0cmlldmluZz0N Cg0KPmNlcnRpZmljYXRlcywNCg0KRGlzYWdyZWUuIFdlIGFyZSBmYXIgZnJvbSB1bmRlcnN0YW5k aW5nIGhvdyBjZXJ0aWZpY2F0ZXMgYXJlIGFuZCB3aWxsID0NCmJlPTIwDQpwdWJsaXNoZWQuIExE QVAgY2VydGlmaWNhdGUgcmV0cmlldmFsIGlzIHdlbGwtZGVmaW5lZCwgYnV0IG5vdCB5ZXQgPQ0K d2lkZWx5PTIwDQppbXBsZW1lbnRlZCwgcGFydGljdWxhcmx5IGZvciBTL01JTUUgTVVBcy4NCltP J01hbGxleSwgQmFydGxleV0gPTIwDQpJcyB0aGlzIHN1ZmZpY2llbnQgZ3JvdW5kcyB0byBqdW5r IGl0PyBJZiBpdCBpcyBub3Qgd2lkZWx5IGltcGxlbWVudGVkID0NCnlldD0yMA0KYmVjYXVzZSBv ZiBpbmhlcmVudCBwcm9ibGVtcywgdGhlbiBmaW5lLCBidXQgaWYgaXQgaXMgc2ltcGx5IGR1ZSB0 byBpdHM9MjANCm5ld25lc3MobXkgdm90ZSkgd2UgcmlzayBkZWxheWluZyB0aGUgaW1wbGVtZW50 YXRpb24gb2YgZWl0aGVyIGJ5IG11ZGR5aW5nID0NCnRoZT0yMA0Kd2F0ZXIgd2l0aCB0aGUgaW50 cm9kdWN0aW9uIG9mIGEgc2Vjb25kLg0KDQo+ICBpdCB3b3VsZCBzZWVtIHRoYXQgYSBkcmFmdCB3 aGljaCBwcm9wb3NlcyBhbiBhbHRlcm5hdGl2ZQ0KPmNlcnQgcHVibGlzaGluZyBtZWNoYW5pc20g YXMgYW4gSW50ZXJuZXQgU3RhbmRhcmQgd291bGQgaGF2ZSBhIGhpZ2gNCj5idXJkZW4gb2YgcHJv b2YgdG8ganVzdGlmeSB0aGUgZHVwbGljYXRpb24uDQoNCklmIHRoaXMgZHJhZnQgd2FzIGNvbWlu ZyBvdXQgdGhyZWUgeWVhcnMgZnJvbSBub3csIHllcy4gQXMgaXQgaXMsIHdlID0NCmhhdmU9MjAN CnNvIGxpdHRsZSB1bmRlcnN0YW5kaW5nIG9mIFMvTUlNRSBjdXN0b21lciBuZWVkcywgSSBkb24n dCB0aGluayBoYXZpbmcgPQ0KYW49MjANCmFsdGVybmF0aXZlIG1lY2hhbmlzbSBpcyBoYXJtZnVs Lg0KDQo+ICAgVGhlIElFU0cgaXMgcmVsYXRpdmVseQ0KPnN0cmljdCBpbiBkaXNjb3VyYWdpbmcg dGhlIGRlZmluaXRpb24gb2Ygb3ZlcmxhcHBpbmcgbWVjaGFuaXNtcy4NCg0KV2Ugb25seSB3aXNo LiA6LSkgQSB0b3BpY2FsbHkgcmVsZXZhbnQgY291bnRlcmV4YW1wbGU6IFMvTUlNRSBhbmQgT3Bl blBHUC4NCg0KW08nTWFsbGV5LCBCYXJ0bGV5XT0yMA0KUGF1c2UgZm9yIGEgbW9tZW50Li4uIERv IHlvdSByZWFsbHk/KHdpc2ggdGhhdCBpcykNCg0KSWYgeW91IGRpZCwgd2h5IHdvdWxkIHlvdSBz dXBwb3J0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgYW4gb3ZlcmxhcHBpbmcgPQ0Kc3RhbmRhcmQuDQoN Ci0tUGF1bCBIb2ZmbWFuLCBEaXJlY3Rvcg0KLS1JbnRlcm5ldCBNYWlsIENvbnNvcnRpdW0NCg0K DQotLV9fX19LWkZPSU1QTUZPTURXRkxYV1dLWV9fX18NCkNvbnRlbnQtVHlwZTogdGV4dC94LXZj YXJkOyBjaGFyc2V0PXdpbmRvd3MtMTI1MjsgbmFtZT0iQm9iIEp1ZW5lbWFuLnZjZiINCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCkNvbnRlbnQtRGlzcG9zaXRp b246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJCb2IgSnVlbmVtYW4udmNmIjsNCgltb2RpZmljYXRp b24tZGF0ZT0iVHVlLCAyNiBPY3QgMTk5OSAxNzoxNTo0OCAtMDYwMCINCg0KQkVHSU46VkNBUkQN ClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpSb2JlcnQgUi4gSnVlbmVtYW4NClRFTDtX T1JLOjgwMS04NjEtNzM4Nw0KT1JHOk5vdmVsbCwgSW5jLjtOZXR3b3JrIFNlY3VyaXR5IERldmVs b3BtZW50DQpURUw7UFJFRjtGQVg6ODAxLTg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJK VUVORU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdp bmVlcg0KQURSO0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjtQUlYtRjMzMTsxMjIgRS4gMTcwMCBT b3V0aDtQcm92bztVdGFoOzg0NjA2O1VTPQ0KQQ0KTEFCRUw7SU5UTDtXT1JLO1BBUkNFTDtQT1NU QUw7RU5DT0RJTkc9M0RRVU9URUQtUFJJTlRBQkxFOlJvYmVydCBSLiA9DQpKdWVuZW1hbj0zRDBB PTNEDQpQUlYtRjMzMT0zRDBBPTNEDQoxMjIgRS4gMTcwMCBTb3V0aD0zRDBBPTNEDQpQcm92bywg VXRhaCAgODQ2MDY9M0QwQT0zRA0KVVNBDQpMQUJFTDtET007V09SSztQQVJDRUw7UE9TVEFMO0VO Q09ESU5HPTNEUVVPVEVELVBSSU5UQUJMRTpSb2JlcnQgUi4gPQ0KSnVlbmVtYW49M0QwQT0zRA0K UFJWLUYzMzE9M0QwQT0zRA0KMTIyIEUuIDE3MDAgU291dGg9M0QwQT0zRA0KUHJvdm8sIFV0YWgg IDg0NjA2DQpURUw7SE9NRToxLTgwMS03NjUtNDM3OA0KVEVMO0NFTEw6MS04MDEtMzYxLTE0MTAN ClRFTDtQUkVGOjEtODAxLTg2MS03Mzg3LCAxLTgwMC00NTMtMTI2Nw0KWC1HV1VTRVJJRDpCSlVF TkVNQU4NCkVORDpWQ0FSRA0KDQoNCi0tX19fX0taRk9JTVBNRk9NRFdGTFhXV0tZX19fXy0tDQqg ggofMIIFCDCCA/CgAwIBAgIaAhQAAAAUNP1e8mQuJK2QmnfLPCP/cgICA9owDQYJKoZIhvcNAQEF BQAwMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DMB4X DTk5MTAwOTE3MjAwMFoXDTA5MTAwOTE3MjAwMFowMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxveWVl IENBMRMwEQYDVQQKFApOT1ZFTExfSU5DMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xVzSeenZZTtL31xxaUyShV7D6ePzgxRoLsakDrf4EQfoxCC0bYfZJKOq9Q0TFbXSd72BcbowK1PR NXRFC5n9dr0Dh73i8ort/tkFhaFsRjEc3Xs4iZAeZZPJ6Et8oQggaBDofvFGfMW3l0YgRPU65+Hu ZqIx/PmqO5IR6XebcNjG3w4BIe54KdI4O2by1M/1FuJIvHpt+YNygt1BXVDv6vlf59jVKp6YFB9m 5KaIm5EjI8AH1Z+dAdT6SvzCTBr7WBolbU76ulSg0fsGvFgu7lREIj2xIh/CjinfXxQQrGb3ddn2 31HjSBZq5zZJOTm/6fxkSq6aRMVmxrnrpaQRMQIDAQABo4ICDjCCAgowCgYDVR0OBAMEAQEwDAYD VR0jBAUwA4ABATAPBgNVHRMBAQAEBTADAQH/MA4GA1UdDwEBAAQEAwIBBjCCAcsGC2CGSAGG+DcB CQQBAQEABIIBtzCCAbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0 cDovL2RldmVsb3Blci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNf djEwLmh0bTCCAUSgGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgw BgIBAQIBCgIBaaIGAgEYAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA AAAAMBgwEAIBAAIIf/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBS oVICAQICAgD/AgEAAw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEB AAIBFDAVMBACAQACCH//////////AQEAAgEUok4wTAIBAgICAP8CAQADDQCA//////////////8D CQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAIIf/////////8BAf8wDQYJKoZI hvcNAQEFBQADggEBAGohEpuwC0ipAiPOo2MnkT8zWs02OH9Bnqakz4ncDOeOoQ2SsZBXyo6KfZ4W QxINEsY+vZC+5paqMFZVOnYKBD4KsD4JT9IwTutBMs6o6K61W56bkjVFaGPujsspsq3Ta8dgxkwU 6rCP4rqyC67dVdm/IqEwFkqfZR6+S8QDsUIE3jTDCP2+QdLE5QJcATW59itW9dRH2HcUppEGX7EF QpnypfMtsahe19vluOWYHXr9PyUMQl5UVaBhDG7IbO1eQBAoPans5/XU8nwl9Z0vmKC5CX9JIb9j K3H6zdUhthBrrFdjVQ8QnVxbi4clscAMVS6COSzSDCxWuD/LwIpwsSUwggUPMIID96ADAgECAhoC FAAAABQ0/V7yZC4krZCad8s8I/9yAgIE6jANBgkqhkiG9w0BAQUFADAyMRswGQYDVQQLExJOb3Zl bGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkxMDA5MTgxODAwWhcNMDEx MDA5MTgxODAwWjBCMRIwEAYDVQQDEwlCSnVlbmVtYW4xDTALBgNVBAsTBE5TUkQxDDAKBgNVBAsT A1BSVjEPMA0GA1UEChMGTm92ZWxsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt3h7 hk+uvRlsxrjGEiL3s5j3RBRdJ23ZYar9CsHmxuVh4uE4i8l+7PJevtAkEQBfaxUIRHYeyNpbYvYY KzTo6OEmb8VND7LUHDfWnerrFzMxwWt+l499ZCVIYLihCqQmlGBplj3KunoS3LsU79J7qtULwBky Kowk+cv7aUsKNp16W/VFzhKWYPApi+jkyo+OHAJh8z5OnRJV8Re0o54ZDTmDb8ILPwH2vu4jl9C7 +r02CXms9XpJSjEqCX+ZmfxGXyY1JH+Yw0XSG+UaINvx1jBLAbz9r4Iga1dZ8FRRgZKX7NasKtAO 4d1HRm5vDZc4BTLNpZbarTjWxomSuVDKAwIDAQABo4ICBTCCAgEwDAYDVR0jBAUwA4ABATAiBgNV HREBAQAEGDAWgRRCSlVFTkVNQU5Abm92ZWxsLmNvbTCCAcsGC2CGSAGG+DcBCQQBAQEABIIBtzCC AbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVsb3Bl ci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCCAUSg GgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaIG AgEUAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAII f/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBSoVICAQICAgD/AgEA Aw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEBAAIBFDAVMBACAQAC CH//////////AQEAAgEUok4wTAIBAgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAS MBACAQACCH//////////AQEAMBIwEAIBAAIIf/////////8BAQAwDQYJKoZIhvcNAQEFBQADggEB AIhCHYqMfOAXyZc/LLjiXUxMJLibE9QG7CwcFsxKcHwUuRURoJTsisJY/BavmxZoJwV//8G1uII7 rYABLsPH1xlGkPXdqsFJ9Ok2vAvAHga+15sax3tR7OGAUH6rVaXW2Q2rIHjoSYSkgDJiG7+42o8C PaGfd2kucPwK5ExhZvoaXsWbEh7U43ChQEPe+zPkMG54pZpwXz2IkJPsv7hnAHiaiUZ5s23625s5 abMqoMiRDQvsw+DubavRp+d6R6RtRJ41/2Td/ozNByiHP6w7kPskOHty0Xnp60W5gKA5Q+ZKxdrH xV6YWz/Oh1DHMrW51w4AW7SmHVbR/5AwzBwjEAUxggF3MIIBcwIBATBQMDIxGzAZBgNVBAsTEk5v dmVsbCBFbXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQwIaAhQAAAAUNP1e8mQuJK2QmnfL PCP/cgICBOowCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQB5+R9hWJGej/xJSwMGx7RbwKGW BrKT5VJZ+10AJNFYzU9OWmSYMtgsJTk8CETXclDR72RaMAMNFsAcSuLNJmqOOtL4kSVYXOl62EcC JlMQsPWZIbJeeaxcohryuyDvh+Y6pm2VOP4dBOm09lpVD7XoozedpgMzTcWsE0m1SdiajyrskQkO sykZPiluRh+s1vpTqflApMMRTXWwxMc3pKS08huNYPE2V48dZpPI4mjA+07bQjXDjr0wx4Hpsb/4 7SOFxQPLEGiH6Mf+OeAvQYEk2HWD+UTHsylPuzsU33/9sZrEiHyEnfCOKvkWCQy+r+D2kfPeeaLJ NaPkNDoCDGWk From owner-ietf-smime@imc.org Wed Oct 27 00:01:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18014 for ; Wed, 27 Oct 1999 00:01:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17315 for ietf-smime-bks; Tue, 26 Oct 1999 20:31:25 -0700 (PDT) Received: from smtp1.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17310 for ; Tue, 26 Oct 1999 20:31:24 -0700 (PDT) Received: from dtasi1 (user38.sj.dialup.innetix.com [209.172.68.101]) by smtp1.walltech.com (8.8.7/8.8.7/walltech-1.28h) with SMTP id UAA09067; Tue, 26 Oct 1999 20:34:04 -0700 (PDT) Message-Id: <3.0.5.32.19991026203235.0091b480@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 26 Oct 1999 20:32:35 -0700 To: V KRISHNA REDDY , ietf-smime@imc.org From: Bruce Greenblatt Subject: Re: S-MIME key length In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As I understand it, the S/MIME spec lets you use any key length that you want, as long as you have an algorithm OID for it... So, you can definitely use 1024 bit keys. At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: >I want the information whether s-mime specification gives us the >flexibilty to use 1024 bit key length.Actually what is the status of the >specification regarding key length. >--krishna > > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From owner-ietf-smime@imc.org Wed Oct 27 03:02:08 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02678 for ; Wed, 27 Oct 1999 03:02:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA22964 for ietf-smime-bks; Tue, 26 Oct 1999 23:28:15 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA22958 for ; Tue, 26 Oct 1999 23:28:05 -0700 (PDT) Received: from localhost (kris@localhost) by cmcltd.com (8.8.7/8.8.7) with ESMTP id MAA29392; Wed, 27 Oct 1999 12:55:20 +0530 Date: Wed, 27 Oct 1999 12:55:20 +0530 (IST) From: V KRISHNA REDDY To: Bruce Greenblatt cc: ietf-smime@imc.org Subject: Re: S-MIME key length In-Reply-To: <3.0.5.32.19991026203235.0091b480@pop.walltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Can you please send me the format for the S/MIME v3 certificates.i.e. I want to have the all the required fields in the smime v3 certificates. --krishna. On Tue, 26 Oct 1999, Bruce Greenblatt wrote: > As I understand it, the S/MIME spec lets you use any key length that you > want, as long as you have an algorithm OID for it... So, you can > definitely use 1024 bit keys. > > At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: > >I want the information whether s-mime specification gives us the > >flexibilty to use 1024 bit key length.Actually what is the status of the > >specification regarding key length. > >--krishna > > > > > > > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com > From owner-ietf-smime@imc.org Wed Oct 27 08:29:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08244 for ; Wed, 27 Oct 1999 08:29:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA00756 for ietf-smime-bks; Wed, 27 Oct 1999 04:04:08 -0700 (PDT) Received: from mta1.lkp.frontec.se (pc254.frontec.se [193.13.194.254]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA00752 for ; Wed, 27 Oct 1999 04:04:04 -0700 (PDT) From: Andreas.Rehn@sth.frontec.se Received: by mta1.lkp.frontec.se(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 80256817.00422ED3 ; Wed, 27 Oct 1999 13:02:53 +0100 X-Lotus-FromDomain: FRONTEC To: ietf-smime@imc.org Message-ID: <80256817.00422E00.00@mta1.lkp.frontec.se> Date: Wed, 27 Oct 1999 13:11:37 +0100 Subject: Problem with signatures Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi I am trying to compose S/MIME messages with signed and encrypted data. My question is: what exactly is the input for the signing procedure? For example(below), should all the pkcs#7-mime headers(and the blank lines) be included when the signature is calculated or is it only the base 64 encrypted data? When this example is opened in Netscape Messenger the decryption works fine but the signature is invalid, I am quite sure that I use the right certificates. please advise Andreas Rehn Message-ID: <941020533@random-pc> Date: Wednesday, 27/10/1999 12:35:33 +0200 From: Anders.Jalm@sth.frontec.se To: Anders.Jalm@sth.frontec.se Subject: encrypted to be signed MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="BOUNDARY" --BOUNDARY Content-Type: application/pkcs7-mime; name="test" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb... ... ...qVSnAAAAAA== --BOUNDARY Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3D... ...UB2KZ9RcTbkAAAAAA== --BOUNDARY-- . From owner-ietf-smime@imc.org Wed Oct 27 09:41:17 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11763 for ; Wed, 27 Oct 1999 09:41:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA02730 for ietf-smime-bks; Wed, 27 Oct 1999 05:45:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02724 for ; Wed, 27 Oct 1999 05:45:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09319; Wed, 27 Oct 1999 08:48:53 -0400 (EDT) Message-Id: <199910271248.IAA09319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-ecc-00.txt Date: Wed, 27 Oct 1999 08:48:53 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Elliptic Curve S/MIME Author(s) : P. Lambert Filename : draft-ietf-smime-ecc-00.txt Pages : Date : 26-Oct-99 This document is the first draft of a profile for the incorporation of Elliptic Curve (EC) public key algorithms in the Cryptographic Message Syntax (CMS). The EC algorithms support the creation of digital signatures and the distribution of keys to encrypt or authen- ticate message content. The definition of the algorithm processing is based on the ANSI X9.63 draft, developed by the ANSI X9F1 working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-ecc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-ecc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991026150244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-ecc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-ecc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026150244.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Wed Oct 27 09:41:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11791 for ; Wed, 27 Oct 1999 09:41:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA01353 for ietf-smime-bks; Wed, 27 Oct 1999 04:34:35 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01331 for ; Wed, 27 Oct 1999 04:33:59 -0700 (PDT) Received: from venky.cmcltd.com ([172.16.16.9]) by cmcltd.com (8.8.7/8.8.7) with SMTP id SAA13845 for ; Wed, 27 Oct 1999 18:03:39 +0530 Message-ID: <00c101bf206f$a6535100$091010ac@venky.cmcltd.com> From: "krishna Reddy" To: Subject: s/mime certificate format Date: Wed, 27 Oct 1999 17:07:27 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01BF209D.BF176900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01BF209D.BF176900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can you plese give the S/MIME v3 certificate format.What are the field = extensions that are necessary for such a certificate. --krishna ------=_NextPart_000_00BE_01BF209D.BF176900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can you plese give the S/MIME v3 = certificate=20 format.What are the field extensions that are necessary for such a=20 certificate.
--krishna
------=_NextPart_000_00BE_01BF209D.BF176900-- From owner-ietf-smime@imc.org Wed Oct 27 11:41:14 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17950 for ; Wed, 27 Oct 1999 11:41:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06546 for ietf-smime-bks; Wed, 27 Oct 1999 07:55:34 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06541 for ; Wed, 27 Oct 1999 07:55:32 -0700 (PDT) Message-Id: <4.2.1.19991027075837.00ccdc20@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 07:59:06 -0700 To: From: Paul Hoffman / IMC Subject: Re: s/mime certificate format In-Reply-To: <00c101bf206f$a6535100$091010ac@venky.cmcltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:07 PM 10/27/99 +0530, krishna Reddy wrote: >Can you plese give the S/MIME v3 certificate format.What are the field >extensions that are necessary for such a certificate. All the RFCs are available from the WG's web site at . --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Wed Oct 27 12:27:03 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20830 for ; Wed, 27 Oct 1999 12:27:02 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA07341 for ietf-smime-bks; Wed, 27 Oct 1999 08:33:47 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07337 for ; Wed, 27 Oct 1999 08:33:46 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910271533.IAA07337@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 09:35:46 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 09:35:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: Re: S-MIME key length To: ietf-smime@imc.org, V KRISHNA REDDY Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____ACYPFYRFVBRYBLIJGPKZ____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____ACYPFYRFVBRYBLIJGPKZ____ Content-Type: multipart/mixed; boundary="____ZTOGZPVTRLXLEKEAXCPG____" --____ZTOGZPVTRLXLEKEAXCPG____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This message is signed with a 2048 bit key. So far, I haven't encountered = anyone who hasn't been able to validate the signature with that length key. = Encryption=20 could conceivably be a different issue, depending on whether or not a = recipient is constrained by export and/or import policy. We've done some limited testing with "odd-ball" key lengths -- 768, and = even odd number such as 1027, etc. No observed problems. Doesn't guarantee that everyone's software will handle such keys, of course. Bob Robert R. Jueneman Security Architect Network Security Development Novell, Inc. 122 East 1700 South Provo, UT 84606 bjueneman@novell.com 1-801-861-7387 DISCLAIMER: If this message (with or without attached documents) is digitally = signed, and/or if certificates are attached, the intended purpose is to=20 (1) Ensure that e-mail came from the apparent sender (2) Protect e-mail from tampering (3) Ensure that the content of e-mail sent to me and encrypted in my = dual-use key cannot be viewed by others. It is explicitly NOT the intent of any such signed message or document = to represent any type or form of legally binding contract or other = representation, and any such interpretation should not be considered = commercially reasonable and WILL BE REPUDIATED, notwithstanding any = wording or implications to the opposite effect in the text of the message = itself; due in part, but not exclusively, to the fact that the security of = my workstation and its associated cryptography is not judged adequately = strong for such purposes at present. >>> Bruce Greenblatt 10/26/99 = 09:32PM >>> As I understand it, the S/MIME spec lets you use any key length that you want, as long as you have an algorithm OID for it... So, you can definitely use 1024 bit keys. At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: >I want the information whether s-mime specification gives us the >flexibilty to use 1024 bit key length.Actually what is the status of the >specification regarding key length. >--krishna=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --____ZTOGZPVTRLXLEKEAXCPG____ Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf" Content-Disposition: attachment; filename="Bob Jueneman.vcf"; modification-date="Wed, 27 Oct 1999 09:35:30 -0600" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US= A LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606=3D0A=3D USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --____ZTOGZPVTRLXLEKEAXCPG____-- --____ACYPFYRFVBRYBLIJGPKZ____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBAEatjb80kubAXhf8bJ3/mHVNDN/KrK2O SuN2GqMik1ux3EASie9K9MjnKVdZ5ec5HbW4I3GlWZkoplIgpY8nnjRgvC7yktw2UJqx2DaAN58d b8hs64UDzF4saCPPWQySWz3yH57ITxYNPBtgpcbp4rNdpf04EgNQSxS04cLXZvFX0hL1teSz00Un tJJeUNb/cUH9/ckjODFPfcDzO3W/P0acpDWQUjM6Vy3m28aVK/mHjFAZEmCq8BrjVROOuLOAwebh ij0TuxCo7YsRIDnKLeeklNUmBM+1dP9xyZHe5K1W+KJSd3+4VmBHfyASV6Zk4SSGkJmG3SdDhvWI ume36Yg= --____ACYPFYRFVBRYBLIJGPKZ____-- From owner-ietf-smime@imc.org Wed Oct 27 13:38:36 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25572 for ; Wed, 27 Oct 1999 13:38:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA09204 for ietf-smime-bks; Wed, 27 Oct 1999 09:39:05 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA09200 for ; Wed, 27 Oct 1999 09:39:04 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910271639.JAA09200@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 10:41:05 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 10:41:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____WADBJNCIRFTLTXQWWZIG____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____WADBJNCIRFTLTXQWWZIG____ Content-Type: multipart/mixed; boundary="____RXPVIHJZACUBDQYIVIQA____" --____RXPVIHJZACUBDQYIVIQA____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Apparently there are people on the list who don't have S/MIME compliant readers, and I accidentally used base64 encoding. Here is the message in clear text form. Bob I'm afraid I strongly disagree with Paul and Rik, and=20 agree with Bartlett and David Kemp instead. I'm speaking as an architect who is responsible for defining our future direction with respect to our GroupWise S/MIME V3 implementation, in addition to our PKI product line, including=20 the Novell Certificate Server 2.0 (which was released just hours ago as a FREE web release -- see=20 http://www.novell.com/press/archive/1999/10/pr99130.html),=20 as well as our LDAP direction in this space. I believe that providing multiple "standard" ways of doing=20 something that is relatively simple inevitably leads to=20 unnecessary duplication of effort, and more importantly, serious interoperability problems between vendors. It's difficult enough to get multiple vendors to do something right when there is only one way to do it. If there are multiple options, as with the current logic for determining what encryption algorithm to use, someone is bound to screw it up, with the result that two different products have difficulty communicating. If I could turn the clock back a year or two, I would have preferred=20 that the SMIME Capabilities attribute be included in the end-user's certificate directly. Failing that, I would have liked to see a "Capabilities" certificate = that=20 is issued and signed by the end-user herself, that in addition to = containing SMIME stuff regarding what algorithms were supported, might also have contained the equivalent of a CPS statement that defends=20 the user, and not just the CA, from unwanted reliance on a signature, for example. If the end-user published such a certificate, it would have = made=20 sense to put it in the same LDAP bucket as the end-user's own certificate. Both of those options are probably foreclosed by now, unfortunately, so we are left with the problem of where to put the SMIME Capabilities, = and where to put the user's S/MIME certificates. With respect to the certificates themselves, I don't think there is any=20 question at all -- all, or nearly all, of the public CAs and CA toolkit = vendors=20 publish the certificates in the already defined LDAP attributes. And from a certificate management perspective, the last thing that either = the user/system administrator or the vendor wants is to have to manage TWO=20 sets of certificates stored in separate places. The possibilities for = errors are obvious -- one certificate gets deleted/replace, and the other one=20 doesn't, etc. I suppose that it could be argued from an LDAP user's perspective that=20 it might be convenient to be able to browse through a directory, find the desired user, and click on one directory attribute to retrieve the = SMIME=20 Capabilities and the entire certificate chain in one operation. I'm = relatively certain that's the scenario that the authors had in mind for this = capability. However, I don't think that's what will happen in practice. Instead, I expect that an e-mail user will type in or select names from=20 his personal or system address book. Then he or she will decide to=20 encrypt the message, without regard to whether or not all of the certificat= es=20 for all of the addressees have already been cached locally. At that point, the MUA should automatically fetch the certificates and=20 SMIME capabilities for all of the users, and perhaps prompt the user=20 to make sure that those are in fact the right certificates for those = users. But the management of the certificate chain, the SMIME Capabilities, = and=20 any other "plumbing" that the user doesn't absolutely have to be exposed = to=20 should be handled by the MUA. So the retrieval of the end-users certificat= e(s),=20 the CA certificates, and the SMIME Capabilities should all be handled=20 automatically, without user intervention. Since it is software that is = going=20 to be doing the retrieval, and not a human user, retrieving from multiple = attributes is not a problem. From this perspective, I think it is obvious that there should be one and = only way to store and retrieve such certificates. Otherwise, it will be = necessary=20 to implement both types of directory fetches, just in case, and that just causes more complexity, code bloat, system and interoperability testing, = etc. Yuck! The current way of retrieving certificates is completely adequate, IMHO. If it ain't broke, don't fix it. Bob >>> 10/26/99 10:16AM >>> -----Original Message----- From: phoffman [SMTP:phoffman@imc.org]=20 Sent: Monday, October 25, 1999 5:09 PM To: ietf-smime Cc: phoffman Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving= >certificates, Disagree. We are far from understanding how certificates are and will = be=20 published. LDAP certificate retrieval is well-defined, but not yet = widely=20 implemented, particularly for S/MIME MUAs. [O'Malley, Bartley] =20 Is this sufficient grounds to junk it? If it is not widely implemented = yet=20 because of inherent problems, then fine, but if it is simply due to its=20 newness(my vote) we risk delaying the implementation of either by muddying = the=20 water with the introduction of a second. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we = have=20 so little understanding of S/MIME customer needs, I don't think having = an=20 alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. [O'Malley, Bartley]=20 Pause for a moment... Do you really?(wish that is) If you did, why would you support the introduction of an overlapping = standard. --Paul Hoffman, Director --Internet Mail Consortium --____RXPVIHJZACUBDQYIVIQA____ Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf" Content-Disposition: attachment; filename="Bob Jueneman.vcf"; modification-date="Wed, 27 Oct 1999 10:37:10 -0600" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US= A LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606=3D0A=3D USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --____RXPVIHJZACUBDQYIVIQA____-- --____WADBJNCIRFTLTXQWWZIG____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBADWOjxnKCxFbFR/v5MyEYjGiwQo3HF9q KfNLZmC7uzeJLuBRMWpYri0MEKvNZmuh89kcfagnx1z5LAGqXtsPuDPOTiIn4GwdNp8r1QG+y9mK HVI4ZCLfZxEFPwkwl5jYNp5sTszzzf96m+PswkckN5BTJl5h/W6jwNs9O2s8xFdWRQ++l5BMuh78 gQcNei8riTayYmTKHILfPLAjNT9cBxrvjs+1A7ccC5mTEbr1jUki18OjsYyzCz8tZZ9q691+t3B7 oHc1mJpKnV7alxj0lNH71ZTXK+A+iK+kPx8grFYHeZkWVDfG6p5AyJyG1DrAkcUpy5voh/1/9R8v qMooLYI= --____WADBJNCIRFTLTXQWWZIG____-- From owner-ietf-smime@imc.org Wed Oct 27 18:13:40 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13012 for ; Wed, 27 Oct 1999 18:13:39 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA14766 for ietf-smime-bks; Wed, 27 Oct 1999 14:32:26 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14762 for ; Wed, 27 Oct 1999 14:32:18 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id OAA00602; Wed, 27 Oct 1999 14:34:44 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <38176FEB.574F61D@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 14:34:35 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: ietf-smime@imc.org, V KRISHNA REDDY Subject: Re: S-MIME key length References: <199910271533.IAA07337@ns.secondary.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms967F7AD330FECC810CCC2CB0" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms967F7AD330FECC810CCC2CB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit BJUENEMAN@novell.com wrote: > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > who hasn't been able to validate the signature with that length key. Encryption > could conceivably be a different issue, depending on whether or not a recipient > is constrained by export and/or import policy. > Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". --------------ms967F7AD330FECC810CCC2CB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKLgYJKoZIhvcNAQcCoIIKHzCCChsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B7owggSEMIID7aADAgECAhAV4oOYVg1pE0gVFzzXJ4WbMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDMyMTAwMDAw MFoXDTAwMDMyMDIzNTk1OVowggEoMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0Rlbm5pcyBHbGF0dGluZzE1MDMGCSqG SIb3DQEJARYmZGVubmlzLmdsYXR0aW5nQHNvZnR3YXJlLW11bml0aW9ucy5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKSBSrAz19P5zPsu3odv359aq1FIuU7RXSXlVga0DqpE ST8T6/e3wtn1f8NnfnytpCWP4r2FgO51Z2Q8o5fy99Gajtlm5tYDBEm09HGWoxAYfEJE8oVI lMCDRQazW5WFiY8WkoNl36eoVl0Oa5rsaSMnk5u45R7Mu3wyLRBooXfnAgMBAAGjggEGMIIB AjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVy aVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2Ug bGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B AQQFAAOBgQAlb2LpvHzHBF/o/uILYbM2MGnIkf4y7PN+XQnMAXpk1mIFeVtIH+kquwCo93ra 9h1wdohBxmPt4Sw/EHG4WNr8PnYXuo7kFOBokqSTOYQTr/6zbSKnjXhO3N4qWKoS0dK0G8GO QTKulULvZBkmbnHJ1YIvES2KH7hC2Uzs1K7SDDCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKo JV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgT Vi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMC AQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0G CSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVq D7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9d WBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEBXig5hWDWkTSBUX PNcnhZswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw05OTEwMjcyMTM0MzVaMCMGCSqGSIb3DQEJBDEWBBTJWx1/ew/mu+iRtbjKaPN/ /iESjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgIye 4H0KwvUxoYqZZtHM44gCRyp6DyV3AceT7OgvbicFwDc7t1IrfwR7dBmTb3xmCVwAG04gOdhE v7BQk0J+vpLzNh/zwDoCYWRuEv1QfE0+pAjZ/jICI/VNQ9/mYNzMLntMcMszxF9dm0Y2ETZ6 nrCBHA7zo+zuNFouac+M8sDV --------------ms967F7AD330FECC810CCC2CB0-- From owner-ietf-smime@imc.org Wed Oct 27 19:17:31 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17464 for ; Wed, 27 Oct 1999 19:17:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16152 for ietf-smime-bks; Wed, 27 Oct 1999 15:49:08 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16147 for ; Wed, 27 Oct 1999 15:49:07 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id SAA28624 for ; Wed, 27 Oct 1999 18:52:39 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id SAA28620 for ; Wed, 27 Oct 1999 18:52:39 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id SAA12374 for ; Wed, 27 Oct 1999 18:52:00 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id SAA08307 for ; Wed, 27 Oct 1999 18:48:32 -0400 (EDT) Message-Id: <199910272248.SAA08307@ara.missi.ncsc.mil> Date: Wed, 27 Oct 1999 18:48:32 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: giLQL6wd2OliyN9c4Ds6Tg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Date: Mon, 25 Oct 1999 09:09:17 -0700 > From: Paul Hoffman / IMC > > Disagree. We are far from understanding how certificates are and will be > published. LDAP certificate retrieval is well-defined, but not yet widely > implemented, particularly for S/MIME MUAs. Ignoring for now the issue of alternatives to LDAP, do you agree with my proposal -- namely, that in the case where LDAP *is* used to carry the SMimeCertificatePublish object, the certificates field shall be empty? From owner-ietf-smime@imc.org Wed Oct 27 19:55:38 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19390 for ; Wed, 27 Oct 1999 19:55:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17067 for ietf-smime-bks; Wed, 27 Oct 1999 16:18:12 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA17061 for ; Wed, 27 Oct 1999 16:18:10 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910272318.QAA17061@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 17:20:42 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 17:20:00 -0600 X-Mailer: Groupwise 5.5.2.1 Cc: ietf-smime@imc.org Subject: Re: S-MIME key length To: dennis.glatting@plaintalk.bellevue.wa.us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____TDAUBBZBTADSZSVVWNHS____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____TDAUBBZBTADSZSVVWNHS____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable And your signed message causes GroupWise to say, effectively, that=20 "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person=20 as the "dennis.glatting@software-munitions.com" that was issued a VeriSign certificate. But did Communicator complain because you don't haven't added the=20 Novell root certificate to your cache of trusted roots, or because your=20 incoming mail processor modified the contents somehow, or was=20 there some other kind of problem? And BTW, Has anyone notied the irony of having these kinds of problem=20 on this list? Maybe we should all start eating our own dog food, and=20 actually use the stuff we're building, on this list in particular? This is signed with a 1024 bit key, using the same root certificate, = which=20 however uses a 2048 bit key. Bob >>> Dennis Glatting 10/27/99 = 03:34PM >>> BJUENEMAN@novell.com wrote: >=20 > This message is signed with a 2048 bit key. So far, I haven't encountere= d anyone > who hasn't been able to validate the signature with that length key. = Encryption > could conceivably be a different issue, depending on whether or not a = recipient > is constrained by export and/or import policy. >=20 Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". --____TDAUBBZBTADSZSVVWNHS____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKxwYJKoZIhvcNAQcCoIIKuDCCCrQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCZsw ggSLMIIDc6ADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgIEZjANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTgxMzAwWhcNMDExMDA5MTgxMzAwWjBCMRIwEAYDVQQDEwlCSnVlbmVtYW4xDTALBgNVBAsT BE5TUkQxDDAKBgNVBAsTA1BSVjEPMA0GA1UEChMGTm92ZWxsMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDtQOLi4Nh63hmnOho34etELuNr/OlosQ8ApPHkOH4C8al+DM02r8tCC3UwP5Dr1/35 mK9vJadCypt1DW9j0FDIx6v/nCfK92Iyp1zRuWxu4dIigERLn9L+qJCld2rFHSGEUKQNFN6enV35 M4TDYErBotXKmZsrAZFLCLgafhYmRQIDAQABo4ICBTCCAgEwDAYDVR0jBAUwA4ABATAiBgNVHREB AQAEGDAWgRRCSlVFTkVNQU5Abm92ZWxsLmNvbTCCAcsGC2CGSAGG+DcBCQQBAQEABIIBtzCCAbME AgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVsb3Blci5u b3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCCAUSgGgEB ADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaIGAgEU AQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAIIf/// //////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBSoVICAQICAgD/AgEAAw0A QAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEBAAIBFDAVMBACAQACCH// ////////AQEAAgEUok4wTAIBAgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADASMBAC AQACCH//////////AQEAMBIwEAIBAAIIf/////////8BAQAwDQYJKoZIhvcNAQEFBQADggEBACgd u//Y7A8xnyLYzcmAjTYs5O6xx8QUkglVIRRC/E/a1NfI0xgscfO4x98mzDBM32rAJRdzsQGiyLHC LsE+zuzMmiF0L5yH8hUG+zWX64zRovvz+b6vELBeE3g9Otc8dO+CoVAqMiIE2zPtatuBO9bRgvt9 0fzVX/mGG5LZMs3wJYlP0rYwl/PryiFLdYTvY60+vdShFM4l6RZD3h0mtXzFUFzKBCukJo+98ACX MAi9/kcR5KtnjGzgyCaCwbS5fYs5AOElxIYFQL5Ht/SMMDWoKdEFkPC8WPjJf9BFVHbLk0fOt0fm iPPEhAsmZW/jngoKq85dGQ+WnMJYZDM/6cYwggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCa d8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkxMDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRsw GQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ56dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jE ILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEULmf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8no S3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8+ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8 em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoibkSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8 WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNIFmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGj ggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSMEBTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0P AQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1 cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9y eS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQEC AQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEA Aw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBAC AQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAA AAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/////////8BAQACARSiTjBMAgEC AgIA/wIBAAMNAID//////////////wMJAID/////////MBIwEAIBAAIIf/////////8BAf8wEjAQ AgEAAgh//////////wEB/zANBgkqhkiG9w0BAQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4 f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0Sxj69kL7mlqowVlU6dgoEPgqwPglP0jBO60Eyzqjo rrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/iurILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B 0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5A ECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4 P8vAinCxJTGB9TCB8gIBATBQMDIxGzAZBgNVBAsTEk5vdmVsbCBFbXBsb3llZSBDQTETMBEGA1UE ChQKTk9WRUxMX0lOQwIaAhQAAAAUNP1e8mQuJK2QmnfLPCP/cgICBGYwCQYFKw4DAhoFADANBgkq hkiG9w0BAQEFAASBgJ0J44QK3D4ET/l4DT978e6+4ImBlE3ELJVPKVFzbopu3uxc58OdSTpOuwvg E3m77J9SWZFQdLg5z7yRZZgjrkjEoVyboN4zTFiDj+krJKH8abOH/1XOW+xGxo6tSCdO1M6PWd20 MFm7A9tmnMUp1E5tNXgIvVZiKe0w3xcp4oyP --____TDAUBBZBTADSZSVVWNHS____-- From owner-ietf-smime@imc.org Wed Oct 27 20:18:32 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20232 for ; Wed, 27 Oct 1999 20:18:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA17499 for ietf-smime-bks; Wed, 27 Oct 1999 16:47:17 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17495 for ; Wed, 27 Oct 1999 16:47:16 -0700 (PDT) Message-Id: <4.2.1.19991027164628.00c01cd0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 16:50:49 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: S-MIME key length In-Reply-To: <199910272318.QAA17061@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? This list is for developing the S/MIME protocol, not for developing S/MIME applications. There's a big difference. Many people are on this list to follow CMS issues that have nothing to do with S/MIME MUAs. I think it's inappropriate to burden them with experiments in interoperability that have nothing to do with the protocol. If people want, I'd be happy to set up an S/MIME developer's list for issues and testing such as this. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Wed Oct 27 20:30:58 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20756 for ; Wed, 27 Oct 1999 20:30:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17590 for ietf-smime-bks; Wed, 27 Oct 1999 16:52:46 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17585 for ; Wed, 27 Oct 1999 16:52:45 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA20034 for ; Wed, 27 Oct 1999 16:55:19 -0700 (PDT) Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FKAD4L00.RN8; Wed, 27 Oct 1999 16:55:33 -0700 Message-ID: <381790DE.C4E0EACC@netscape.com> Date: Wed, 27 Oct 1999 16:55:10 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: dennis.glatting@plaintalk.bellevue.wa.us, ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272318.QAA17061@ns.secondary.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms98CFEB9A6CFBEDC9357B9F0C" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms98CFEB9A6CFBEDC9357B9F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Bob, Dennis' message appears invalid to me (Communicator) for the same reason you give. And yours is invalid because it's issued by Novell, which I don't trust (yet?). Yes, I find it amusing that there are complaints about perfectly valid S/MIME messages on this list. You would think this would be one of the few places that you could send signed messages without worrying about confusing the person at the other end. Terry BJUENEMAN@novell.com wrote: > And your signed message causes GroupWise to say, effectively, that > "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person > as the "dennis.glatting@software-munitions.com" that was issued a VeriSign > certificate. > > But did Communicator complain because you don't haven't added the > Novell root certificate to your cache of trusted roots, or because your > incoming mail processor modified the contents somehow, or was > there some other kind of problem? > > And BTW, Has anyone notied the irony of having these kinds of problem > on this list? Maybe we should all start eating our own dog food, and > actually use the stuff we're building, on this list in particular? > > This is signed with a 1024 bit key, using the same root certificate, which > however uses a 2048 bit key. > > Bob > > >>> Dennis Glatting 10/27/99 03:34PM >>> > BJUENEMAN@novell.com wrote: > > > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > > who hasn't been able to validate the signature with that length key. Encryption > > could conceivably be a different issue, depending on whether or not a recipient > > is constrained by export and/or import policy. > > > > Funny you should mention that. When I clicked to read your message my > Netscape 4.61 Communicator displays an icon stating "Invalid > Signature". --------------ms98CFEB9A6CFBEDC9357B9F0C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAAAAAA AACgggk0MIIC2DCCAkGgAwIBAgICDXwwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTkxMDE0MTY1MzQ5WhcNMDAwNDExMTY1 MzQ5WjCBgTETMBEGCgmSJomT8ixkARkWA2NvbTEYMBYGCgmSJomT8ixkARkWCG5ldHNjYXBl MSIwIAYJKoZIhvcNAQkBFhN0aGF5ZXNAbmV0c2NhcGUuY29tMRQwEgYDVQQDEwtUZXJyeSBI YXllczEWMBQGCgmSJomT8ixkAQETBnRoYXllczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA1s8GICPyR1kQqA7mGRxdCi21lINNAmaSfR8y8gztgiEs62usFTxN3n3SeEuJ98G0eGe2 YYrFLOH184Y5ASEa/SBqakbBptQvX2/u+iuFlPksYOG2p+iYNMSZrfZWFkHfaNaVWTcEOpgf 9zhOulQi7QAQS6flGkiZdIfTa2TudpUCAwEAAaNLMEkwDwYDVR0PAQH/BAUDAweAADA2Bggr BgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0G CSqGSIb3DQEBBAUAA4GBABOS1W/NATBPFkABX3iOReoTX6GA9rbpRIk/ldB12X1Rtb9OyW+v xPsGJY+uaxqOd/HBNegVuTmceBgIIY2yJS0hYMU2+jceeX58CFw+sLfsBDhqjHGV09BosrvV jh8JUGoZCCXYHhKmQT9T6Z7WHac4daUmlDC6VlZTwz50BP/2MIIDRTCCAq6gAwIBAgIBJzAN BgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZ EarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB /AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNV HSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/ QbQHCDkMIfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDV Yjtw1Q6xZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqB DSmOneQPMwuPjSQ97DCCAwswggJ0oAMCAQICAg17MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYD VQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoT EkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UE AxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk5MTAxNDE2NTM0OVoXDTAw MDQxMTE2NTM0OVowgYExEzARBgoJkiaJk/IsZAEZFgNjb20xGDAWBgoJkiaJk/IsZAEZFghu ZXRzY2FwZTEiMCAGCSqGSIb3DQEJARYTdGhheWVzQG5ldHNjYXBlLmNvbTEUMBIGA1UEAxML VGVycnkgSGF5ZXMxFjAUBgoJkiaJk/IsZAEBEwZ0aGF5ZXMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAM6wWpjQcG/jYOKlYe4KJTGzFh+MD3RD5d/MIOt6a0/fUC7zS1FOl4fisUH4 SyWKhFY5cmIlQfhnSyyEyibktAf20h09GcPdIc5RnV8Spwngc3FhRnT0/gQS+Lz/Q1T777Rl gqZrcBbAWRx7tgLkpWYd9OanZGXqSYxlNestTP8PAgMBAAGjfjB8MA4GA1UdDwEB/wQEAwIF IDARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUojtlMvf3G4n8VQ0HAbyHSFr9kD0w NgYIKwYBBQUHAQEEKjAoMCYGCCsGAQUFBzABhhpodHRwOi8vbnNvY3NwLm5ldHNjYXBlLmNv bTANBgkqhkiG9w0BAQQFAAOBgQDQGuP8NV5Mn5m5jIzMMy4GQh3km10XnG5xicU5X6CWFjrf irkhxJWrK6UdN5Txpwums9UAj5kp/HkFenUgVuoCqiezvTEDLvZLmqbnCxOPY2xqIr/hjD6R FImDJklzb52sb0HTgFuHW7fGKX+PYeeIPwQE5PJRzw9sgnN3xrGBMjGCAfUwggHxAgEBMIGa MIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcx GzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2ll czEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgINfDAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAy NzIzNTUxM1owIwYJKoZIhvcNAQkEMRYEFFyuYvxBCYorLwrGaYg922O5buVxMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGALpqAwEuIsfZFfITISrx6 2p0RbcHE1qNNrp/JRzyAuiai5Ubh1CCNLfmQeEu5sHiEpx12KMFgp31UDS9UiN1WxktUQOtz yk3VG7eCFLM30OR8cBK/8w+38YxThhO+QI9i7gA0DaJ04i37KjsEIa6W7uImrjWX5fJ4mv3X 80r1dGwAAAAAAAA= --------------ms98CFEB9A6CFBEDC9357B9F0C-- From owner-ietf-smime@imc.org Wed Oct 27 23:07:18 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26356 for ; Wed, 27 Oct 1999 23:07:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23492 for ietf-smime-bks; Wed, 27 Oct 1999 19:38:34 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23486 for ; Wed, 27 Oct 1999 19:38:33 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id TAA02827; Wed, 27 Oct 1999 19:39:22 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <3817B75A.9EF81AA7@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 19:39:22 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Hayes CC: BJUENEMAN@novell.com, ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272318.QAA17061@ns.secondary.com> <381790DE.C4E0EACC@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Terry Hayes wrote: > > Thanks Bob, > > Dennis' message appears invalid to me (Communicator) for > the same reason you give. And yours is invalid because it's > issued by Novell, which I don't trust (yet?). > My NS reader says your signature is good. From owner-ietf-smime@imc.org Wed Oct 27 23:09:13 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26403 for ; Wed, 27 Oct 1999 23:09:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23403 for ietf-smime-bks; Wed, 27 Oct 1999 19:35:11 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23399 for ; Wed, 27 Oct 1999 19:35:10 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id TAA02814; Wed, 27 Oct 1999 19:37:47 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <3817B6FB.BE32E40E@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 19:37:47 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272320.QAA01392@btw.plaintalk.bellevue.wa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit BJUENEMAN@novell.com wrote: > > And your signed message causes GroupWise to say, effectively, that > "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person > as the "dennis.glatting@software-munitions.com" that was issued a > VeriSign certificate. > Damn. I thought I changed my cert. Obviously I did not. I will fix that. > But did Communicator complain because you don't haven't added the > Novell root certificate to your cache of trusted roots, or because your > incoming mail processor modified the contents somehow, or was > there some other kind of problem? > I did not add a Novell root cert. However, NS says there is a "NOVELL EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read your messages I notice your cert listed in "Other People's Certificates." I can add that cert but I don't that that is your point, is it? It's possible my mail tool modified the input. I am working on my mail environment, turning off my NeXTSTEP machines, using different mail tools, adding TLS to secure IMAP transport -- generally having fun. When I click on the Invalid Signature icon associated with your messages NS displays: The Certificate that was used to digitally sign this message is invalid. The error was: The certificate issuer for this server has been marked as not trusted by the user. Netscape refuses to connect to this server. (I did?) This message included the Security Certificate for BJueneman. To check the Certificate or edit Certificate Trust Information, press the ``View/Edit'' button. This Certificate has automatically been added to your list of People's Certificates to make it possible for you to send secure mail to this person. What do you suggest I do? > And BTW, Has anyone notied the irony of having these kinds of problem > on this list? Maybe we should all start eating our own dog food, and > actually use the stuff we're building, on this list in particular? > Sure. I'm game. Though I have done much reading on PK standards and read various other books over the years I haven't really used the technologies, mostly due to stupid vendor implementations (my favorite is buying a "recently released" package in May of 1999 that wasn't Y2K compliant and required me to downgrade the NT server to a non-Y2K version), compatibility issues, implementation issues, licensing issues, etc. So, since I am between projects and have time on my hands, to use your own words, I'm eating my own dog food. :) > This is signed with a 1024 bit key, using the same root certificate, > which however uses a 2048 bit key. > Let's resolve this issue off-line. From owner-ietf-smime@imc.org Thu Oct 28 10:45:41 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24046 for ; Thu, 28 Oct 1999 10:45:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA08700 for ietf-smime-bks; Thu, 28 Oct 1999 06:39:09 -0700 (PDT) Received: from mail.bcbsfl.com ([157.174.220.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08696 for ; Thu, 28 Oct 1999 06:39:08 -0700 (PDT) Received: from 157.174.228.220 by mail.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 28 Oct 99 09:41: 37 -0400 X-Server-Uuid: ce89229e-6f44-11d2-930e-00805f65671f Received: from 157.174.149.239 by wsse.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 28 Oct 99 09:43: 02 -0400 X-Server-Uuid: 1f3d01f6-3236-11d2-8b2f-00c04f971bc8 X-Server-Uuid: 25439fb6-7579-11d1-978b-00a024cc3d5c From: "Ward, Jon" To: "'BJUENEMAN@novell.com'" , cc: Subject: RE: S-MIME key length Date: Thu, 28 Oct 1999 09:41:41 -0400 MIME-Version: 1.0 X-WSS-ID: 14068D1526466-01-02 X-WSS-ID: 14068D6C117060-01-02 X-WSS-ID: 14068D1B39989-01-02 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF214A.3092B722" Message-ID: <14068D1B39989-01@Blue_Cross_Blue_Shield_of_Florida> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF214A.3092B722 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit We, at Blue Cross, are using an SMTP relay with a combined S/MIME Proxy that stores certificates, performs the encryption, signing, decryption and validation of signatures at the proxy as the messages pass the proverbial gate. It attaches an explanation of the message's security status to incoming messages. I have attached the "alert" file itself as an example. It explains that the certificate was not verifiable because we don't trust Novell's root certificate yet. So, we are eating our own dog food, and are not facing a significant obstacle with 2048 bit keys. We will trust the root certificate and monitor the status of new, incoming, signed messages. Further bulletins will follow as events warrant. Jon Ward Senior Systems Analyst/Messaging Architecture Blue Cross Blue Shield of Florida Voice: +1 (904) 791-6057 Jon.Ward@bcbsfl.com -----Original Message----- From: BJUENEMAN@novell.com [mailto:BJUENEMAN@novell.com] Sent: Wednesday, October 27, 1999 7:20 PM To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ietf-smime@imc.org Subject: Re: S-MIME key length And your signed message causes GroupWise to say, effectively, that "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person as the "dennis.glatting@software-munitions.com" that was issued a VeriSign certificate. But did Communicator complain because you don't haven't added the Novell root certificate to your cache of trusted roots, or because your incoming mail processor modified the contents somehow, or was there some other kind of problem? And BTW, Has anyone notied the irony of having these kinds of problem on this list? Maybe we should all start eating our own dog food, and actually use the stuff we're building, on this list in particular? This is signed with a 1024 bit key, using the same root certificate, which however uses a 2048 bit key. Bob >>> Dennis Glatting 10/27/99 03:34PM >>> BJUENEMAN@novell.com wrote: > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > who hasn't been able to validate the signature with that length key. Encryption > could conceivably be a different issue, depending on whether or not a recipient > is constrained by export and/or import policy. > Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". ------_=_NextPart_000_01BF214A.3092B722 Content-Type: text/plain; charset=us-ascii; name=wssalert.txt Content-Disposition: attachment; filename=wssalert.txt Content-Transfer-Encoding: 7bit "Blue Cross Blue Shield of Florida" made the following annotations on 10/27/99 13:05:06 ------------------------------------------------------------------------------ [ALERT] -- Security Manager: Message security properties: Encrypted: No Signed by Sender: Unknown Contents Altered after signing: No Signature Algorithm: SHA1 The message encryption and/or signature are unacceptable for the following reasons: The signing certificate is not associated with the sender of the message. The signing certificate is either not valid or not trusted. ============================================================================== ------_=_NextPart_000_01BF214A.3092B722-- From owner-ietf-smime@imc.org Thu Oct 28 14:16:38 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02696 for ; Thu, 28 Oct 1999 14:16:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11326 for ietf-smime-bks; Thu, 28 Oct 1999 09:32:09 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11320 for ; Thu, 28 Oct 1999 09:32:07 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910281632.JAA11320@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 28 Oct 1999 10:34:50 -0600 Mime-Version: 1.0 Date: Thu, 28 Oct 1999 10:34:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: S/MIME interoperability testing. To: "phoffman@imc.org"@ns.secondary.com, ietf-smime@imc.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____GZVGTAQPUTWDHONHLVJX____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____GZVGTAQPUTWDHONHLVJX____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Paul, I strongly support the idea of setting up an S/MIME-clean list server that could be used for real-world S/MIME interoperability=20 testing. The results of my own rather extensive testing showed that although the various products are relatively clean (but far from perfect), the various list servers, corporate mail gateways, virus=20 checking software, etc., etc., were far from being ready to=20 handled signed or encrypted mail. Testing all of the various combinations of mail processors, certificate issuing software, etc., is quite time consuming for any individual vendors, yet by spreading the load across a number of cooperating users, can be accomplished rather easily. Let's do it. And a hearty thank you to you, if you'll set up the list. Bob Signed with my 2048 bit dual-use key, in cleartext. >>> Paul Hoffman / IMC 10/27/99 05:50PM >>> At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? This list is for developing the S/MIME protocol, not for developing = S/MIME=20 applications. There's a big difference. Many people are on this list to=20 follow CMS issues that have nothing to do with S/MIME MUAs. I think = it's=20 inappropriate to burden them with experiments in interoperability that = have=20 nothing to do with the protocol. If people want, I'd be happy to set up an S/MIME developer's list for=20 issues and testing such as this. --Paul Hoffman, Director --Internet Mail Consortium --____GZVGTAQPUTWDHONHLVJX____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBAF8cJdfvxfNPpFgM1kroe+Cf24Gn7YK0 vX7E7U+qOcq5VVCTRXJl0Y+1g7lh9jYSYKtu/2QL23pWC/pxH96TZeacqLGZyi9iivrLGZvNl16d uVWz2tlGLgxZuccrhaK1vo6f8ESKZmF9VSqSWnoXorVIXuK8hxkMVa7CzMxviGDbX4wt+PfcCieI zHM32JDrHaU5L1Emuo6kG6DZ1CuX9lCHl/7Uv1Ebb17mvYJ4L0YjJb6kGNkWTOVzY06NObkP35Wn nAbiW8lVW/fT6NE8ovbcph4n9/gt9TmHleyOsG8feSYEfOTDNqFa7z1YiCYclYoqPnunIv03vk09 /6zy4aQ= --____GZVGTAQPUTWDHONHLVJX____-- From owner-ietf-smime@imc.org Thu Oct 28 15:17:06 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07066 for ; Thu, 28 Oct 1999 15:17:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13326 for ietf-smime-bks; Thu, 28 Oct 1999 11:33:25 -0700 (PDT) Received: from dylithium.adga.ca (adga.ca [206.222.76.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13322 for ; Thu, 28 Oct 1999 11:33:23 -0700 (PDT) Received: from xfile (blackhole.abnet.net [209.112.11.3]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id OAA25327; Thu, 28 Oct 1999 14:34:30 -0400 (EDT) Message-Id: <3.0.1.32.19991028142917.009a2100@adga.ca> X-Sender: frousseau@adga.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 28 Oct 1999 14:29:17 -0400 To: ietf-smime@imc.org From: Francois Rousseau Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt In-Reply-To: <199910271248.IAA09319@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA13323 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I was very please to see this new Internet Draft for the support of Elliptic Curve Cryptography (ECC) under S/MIME Version 3. What do others think about also supporting "key transport" using ECC in the next version of this Internet Draft in addition to supporting ECC based digital signatures and key agreements? François Rousseau At 08:48 AM 27/10/99 -0400, you wrote: >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 : Elliptic Curve S/MIME > Author(s) : P. Lambert > Filename : draft-ietf-smime-ecc-00.txt > Pages : > Date : 26-Oct-99 > >This document is the first draft of a profile for the incorporation >of Elliptic Curve (EC) public key algorithms in the Cryptographic >Message Syntax (CMS). The EC algorithms support the creation of >digital signatures and the distribution of keys to encrypt or authen- >ticate message content. The definition of the algorithm processing >is based on the ANSI X9.63 draft, developed by the ANSI X9F1 >working group. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-smime-ecc-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-smime-ecc-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > From owner-ietf-smime@imc.org Thu Oct 28 18:03:07 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15471 for ; Thu, 28 Oct 1999 18:03:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA16771 for ietf-smime-bks; Thu, 28 Oct 1999 14:28:52 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16767 for ; Thu, 28 Oct 1999 14:28:51 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA06612; Thu, 28 Oct 1999 14:23:42 -0700 (PDT) Message-Id: <4.2.0.58.19991028132907.009ef860@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 28 Oct 1999 13:43:05 -0500 To: BJUENEMAN@novell.com From: Russ Housley Subject: Re: dog food Cc: ietf-smime@imc.org In-Reply-To: <199910272318.QAA17061@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob: While there is some irony in the situation, S/MIME-enabled mail clients are not a requirement to participate in this IETF Working Group. We want to allow the widest possible participation on this list. Russ S/MIME WG Chair At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >[snip] >And BTW, Has anyone notied the irony of having these kinds of problem >on this list? Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? >[snip] From owner-ietf-smime@imc.org Thu Oct 28 19:01:07 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18495 for ; Thu, 28 Oct 1999 19:01:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17393 for ietf-smime-bks; Thu, 28 Oct 1999 15:22:47 -0700 (PDT) Received: from ghoti.mcom.com (h-208-12-62-56.netscape.com [208.12.62.56]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17389 for ; Thu, 28 Oct 1999 15:22:46 -0700 (PDT) Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (950413.SGI.8.6.12/8.6.9) with SMTP id PAA12403; Thu, 28 Oct 1999 15:25:56 -0700 Message-ID: <3818CD74.EBB1BAAA@netscape.com> Date: Thu, 28 Oct 1999 15:25:56 -0700 From: Lisa Repka Organization: Netscape Communications Corporation X-Mailer: Mozilla 3.02 (X11; U; IRIX 6.2 IP22) MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272320.QAA01392@btw.plaintalk.bellevue.wa.us> <3817B6FB.BE32E40E@plaintalk.bellevue.wa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dennis Glatting wrote: > > I did not add a Novell root cert. However, NS says there is a "NOVELL > EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read > your messages I notice your cert listed in "Other People's > Certificates." I can add that cert but I don't that that is your > point, is it? It may not be a problem of having the cert, just of trust. More below. > It's possible my mail tool modified the input. I am working on my mail > environment, turning off my NeXTSTEP machines, using different mail > tools, adding TLS to secure IMAP transport -- generally having fun. If the hash-matching were the problem, you would have seen a different error than what you saw. > When I click on the Invalid Signature icon associated with your > messages NS displays: > > The Certificate that was used to digitally > sign this message is invalid. > > The error was: The certificate issuer for > this server has been marked as not trusted > by the user. Netscape refuses to connect > to this server. > > (I did?) Please ignore the "Netscape refuses to connect to this server." and imagine the "for this server" was "for this user" or "for this peer" or something slightly better like that. (And don't blame me. It's a long story (and this is hardly our worst error message, either. ;-) Short explanation: it's a shared error message that was originally written when the only thing you did with certificates was SSL.) What it comes down to is that it means your problem was one of trust, not of keysize (or modified input). > What do you suggest I do? You can do one of two things. You can trust Bob's individual cert directly, or you can trust his CA cert. Both can be accomplished via the Security Info (aka Security Advisor; also same thing that comes up when you click on the Invalid Signature icon in the message or when you click on the Security button in the toolbar). The CA cert should show up in the Signers page; Bob's individual cert in the People page. It sounds like you've already located both. Select the one you want to trust, and then click on Edit to change the trust. (BTW, if you're paranoid, you would check that the cert you are trusting is really the cert you should trust. For example by calling Bob and asking him to tell you his certificate's fingerprint. Not that anybody, including those of us who presumably "know better" *ever* do this. ;-) lisa From owner-ietf-smime@imc.org Fri Oct 29 15:16:56 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14324 for ; Fri, 29 Oct 1999 15:16:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20154 for ietf-smime-bks; Fri, 29 Oct 1999 11:37:46 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20149 for ; Fri, 29 Oct 1999 11:37:45 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.66.108.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA27023 for ; Fri, 29 Oct 1999 11:32:48 -0700 (PDT) Message-Id: <4.2.0.58.19991029112406.009d8ab0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 29 Oct 1999 11:29:29 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit François: >I was very please to see this new Internet Draft for the support of >Elliptic Curve Cryptography (ECC) under S/MIME Version 3. > >What do others think about also supporting "key transport" using ECC in the >next version of this Internet Draft in addition to supporting ECC based >digital signatures and key agreements? Most of the EC key management work that I have seen uses EC D-H (key agreement). As the S/MIME WG chairman, it is my responsibility to ensure that we document the algorithm suites that have a constituency; not that we document every possible algorithm suite. Where do you see EC key transport being used? Russ From owner-ietf-smime@imc.org Sat Oct 30 23:00:59 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13299 for ; Sat, 30 Oct 1999 23:00:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08959 for ietf-smime-bks; Sat, 30 Oct 1999 19:29:59 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08953; Sat, 30 Oct 1999 19:29:58 -0700 (PDT) Message-Id: <4.2.1.19991030193013.00a57690@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sat, 30 Oct 1999 19:33:17 -0700 To: ietf-smime@imc.org, ietf-ediint@imc.org From: Paul Hoffman / IMC Subject: New list for S/MIME developers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the request of a couple of S/MIME folks on the ietf-smime list, I've set up a new mailing list for discussing implementation of S/MIME. Note that this new list is *not* for discussing the S/MIME spec; the ietf-smime list is still doing quite a good job of that. But the new list will be a good place to ask about who has actually implemented what and to send sample messages. The list is called imc-smime-dev@imc.org. To subscribe, send a message to: imc-smime-dev-request@imc.org with the single word subscribe in the body of the message. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08959 for ietf-smime-bks; Sat, 30 Oct 1999 19:29:59 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08953; Sat, 30 Oct 1999 19:29:58 -0700 (PDT) Message-Id: <4.2.1.19991030193013.00a57690@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sat, 30 Oct 1999 19:33:17 -0700 To: ietf-smime@imc.org, ietf-ediint@imc.org From: Paul Hoffman / IMC Subject: New list for S/MIME developers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the request of a couple of S/MIME folks on the ietf-smime list, I've set up a new mailing list for discussing implementation of S/MIME. Note that this new list is *not* for discussing the S/MIME spec; the ietf-smime list is still doing quite a good job of that. But the new list will be a good place to ask about who has actually implemented what and to send sample messages. The list is called imc-smime-dev@imc.org. To subscribe, send a message to: imc-smime-dev-request@imc.org with the single word subscribe in the body of the message. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20154 for ietf-smime-bks; Fri, 29 Oct 1999 11:37:46 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20149 for ; Fri, 29 Oct 1999 11:37:45 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.66.108.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA27023 for ; Fri, 29 Oct 1999 11:32:48 -0700 (PDT) Message-Id: <4.2.0.58.19991029112406.009d8ab0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 29 Oct 1999 11:29:29 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: François: >I was very please to see this new Internet Draft for the support of >Elliptic Curve Cryptography (ECC) under S/MIME Version 3. > >What do others think about also supporting "key transport" using ECC in the >next version of this Internet Draft in addition to supporting ECC based >digital signatures and key agreements? Most of the EC key management work that I have seen uses EC D-H (key agreement). As the S/MIME WG chairman, it is my responsibility to ensure that we document the algorithm suites that have a constituency; not that we document every possible algorithm suite. Where do you see EC key transport being used? Russ Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17393 for ietf-smime-bks; Thu, 28 Oct 1999 15:22:47 -0700 (PDT) Received: from ghoti.mcom.com (h-208-12-62-56.netscape.com [208.12.62.56]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17389 for ; Thu, 28 Oct 1999 15:22:46 -0700 (PDT) Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (950413.SGI.8.6.12/8.6.9) with SMTP id PAA12403; Thu, 28 Oct 1999 15:25:56 -0700 Message-ID: <3818CD74.EBB1BAAA@netscape.com> Date: Thu, 28 Oct 1999 15:25:56 -0700 From: Lisa Repka Organization: Netscape Communications Corporation X-Mailer: Mozilla 3.02 (X11; U; IRIX 6.2 IP22) MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272320.QAA01392@btw.plaintalk.bellevue.wa.us> <3817B6FB.BE32E40E@plaintalk.bellevue.wa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dennis Glatting wrote: > > I did not add a Novell root cert. However, NS says there is a "NOVELL > EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read > your messages I notice your cert listed in "Other People's > Certificates." I can add that cert but I don't that that is your > point, is it? It may not be a problem of having the cert, just of trust. More below. > It's possible my mail tool modified the input. I am working on my mail > environment, turning off my NeXTSTEP machines, using different mail > tools, adding TLS to secure IMAP transport -- generally having fun. If the hash-matching were the problem, you would have seen a different error than what you saw. > When I click on the Invalid Signature icon associated with your > messages NS displays: > > The Certificate that was used to digitally > sign this message is invalid. > > The error was: The certificate issuer for > this server has been marked as not trusted > by the user. Netscape refuses to connect > to this server. > > (I did?) Please ignore the "Netscape refuses to connect to this server." and imagine the "for this server" was "for this user" or "for this peer" or something slightly better like that. (And don't blame me. It's a long story (and this is hardly our worst error message, either. ;-) Short explanation: it's a shared error message that was originally written when the only thing you did with certificates was SSL.) What it comes down to is that it means your problem was one of trust, not of keysize (or modified input). > What do you suggest I do? You can do one of two things. You can trust Bob's individual cert directly, or you can trust his CA cert. Both can be accomplished via the Security Info (aka Security Advisor; also same thing that comes up when you click on the Invalid Signature icon in the message or when you click on the Security button in the toolbar). The CA cert should show up in the Signers page; Bob's individual cert in the People page. It sounds like you've already located both. Select the one you want to trust, and then click on Edit to change the trust. (BTW, if you're paranoid, you would check that the cert you are trusting is really the cert you should trust. For example by calling Bob and asking him to tell you his certificate's fingerprint. Not that anybody, including those of us who presumably "know better" *ever* do this. ;-) lisa Received: by ns.secondary.com (8.9.3/8.9.3) id OAA16771 for ietf-smime-bks; Thu, 28 Oct 1999 14:28:52 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16767 for ; Thu, 28 Oct 1999 14:28:51 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA06612; Thu, 28 Oct 1999 14:23:42 -0700 (PDT) Message-Id: <4.2.0.58.19991028132907.009ef860@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 28 Oct 1999 13:43:05 -0500 To: BJUENEMAN@novell.com From: Russ Housley Subject: Re: dog food Cc: ietf-smime@imc.org In-Reply-To: <199910272318.QAA17061@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob: While there is some irony in the situation, S/MIME-enabled mail clients are not a requirement to participate in this IETF Working Group. We want to allow the widest possible participation on this list. Russ S/MIME WG Chair At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >[snip] >And BTW, Has anyone notied the irony of having these kinds of problem >on this list? Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? >[snip] Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13326 for ietf-smime-bks; Thu, 28 Oct 1999 11:33:25 -0700 (PDT) Received: from dylithium.adga.ca (adga.ca [206.222.76.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13322 for ; Thu, 28 Oct 1999 11:33:23 -0700 (PDT) Received: from xfile (blackhole.abnet.net [209.112.11.3]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id OAA25327; Thu, 28 Oct 1999 14:34:30 -0400 (EDT) Message-Id: <3.0.1.32.19991028142917.009a2100@adga.ca> X-Sender: frousseau@adga.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 28 Oct 1999 14:29:17 -0400 To: ietf-smime@imc.org From: Francois Rousseau Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt In-Reply-To: <199910271248.IAA09319@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA13323 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I was very please to see this new Internet Draft for the support of Elliptic Curve Cryptography (ECC) under S/MIME Version 3. What do others think about also supporting "key transport" using ECC in the next version of this Internet Draft in addition to supporting ECC based digital signatures and key agreements? François Rousseau At 08:48 AM 27/10/99 -0400, you wrote: >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 : Elliptic Curve S/MIME > Author(s) : P. Lambert > Filename : draft-ietf-smime-ecc-00.txt > Pages : > Date : 26-Oct-99 > >This document is the first draft of a profile for the incorporation >of Elliptic Curve (EC) public key algorithms in the Cryptographic >Message Syntax (CMS). The EC algorithms support the creation of >digital signatures and the distribution of keys to encrypt or authen- >ticate message content. The definition of the algorithm processing >is based on the ANSI X9.63 draft, developed by the ANSI X9F1 >working group. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-smime-ecc-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-smime-ecc-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11326 for ietf-smime-bks; Thu, 28 Oct 1999 09:32:09 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11320 for ; Thu, 28 Oct 1999 09:32:07 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910281632.JAA11320@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 28 Oct 1999 10:34:50 -0600 Mime-Version: 1.0 Date: Thu, 28 Oct 1999 10:34:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: S/MIME interoperability testing. To: "phoffman@imc.org", ietf-smime@imc.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____GZVGTAQPUTWDHONHLVJX____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____GZVGTAQPUTWDHONHLVJX____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Paul, I strongly support the idea of setting up an S/MIME-clean list server that could be used for real-world S/MIME interoperability=20 testing. The results of my own rather extensive testing showed that although the various products are relatively clean (but far from perfect), the various list servers, corporate mail gateways, virus=20 checking software, etc., etc., were far from being ready to=20 handled signed or encrypted mail. Testing all of the various combinations of mail processors, certificate issuing software, etc., is quite time consuming for any individual vendors, yet by spreading the load across a number of cooperating users, can be accomplished rather easily. Let's do it. And a hearty thank you to you, if you'll set up the list. Bob Signed with my 2048 bit dual-use key, in cleartext. >>> Paul Hoffman / IMC 10/27/99 05:50PM >>> At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? This list is for developing the S/MIME protocol, not for developing = S/MIME=20 applications. There's a big difference. Many people are on this list to=20 follow CMS issues that have nothing to do with S/MIME MUAs. I think = it's=20 inappropriate to burden them with experiments in interoperability that = have=20 nothing to do with the protocol. If people want, I'd be happy to set up an S/MIME developer's list for=20 issues and testing such as this. --Paul Hoffman, Director --Internet Mail Consortium --____GZVGTAQPUTWDHONHLVJX____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBAF8cJdfvxfNPpFgM1kroe+Cf24Gn7YK0 vX7E7U+qOcq5VVCTRXJl0Y+1g7lh9jYSYKtu/2QL23pWC/pxH96TZeacqLGZyi9iivrLGZvNl16d uVWz2tlGLgxZuccrhaK1vo6f8ESKZmF9VSqSWnoXorVIXuK8hxkMVa7CzMxviGDbX4wt+PfcCieI zHM32JDrHaU5L1Emuo6kG6DZ1CuX9lCHl/7Uv1Ebb17mvYJ4L0YjJb6kGNkWTOVzY06NObkP35Wn nAbiW8lVW/fT6NE8ovbcph4n9/gt9TmHleyOsG8feSYEfOTDNqFa7z1YiCYclYoqPnunIv03vk09 /6zy4aQ= --____GZVGTAQPUTWDHONHLVJX____-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA08700 for ietf-smime-bks; Thu, 28 Oct 1999 06:39:09 -0700 (PDT) Received: from mail.bcbsfl.com ([157.174.220.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08696 for ; Thu, 28 Oct 1999 06:39:08 -0700 (PDT) Received: from 157.174.228.220 by mail.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 28 Oct 99 09:41: 37 -0400 X-Server-Uuid: ce89229e-6f44-11d2-930e-00805f65671f Received: from 157.174.149.239 by wsse.bcbsfl.com with ESMTP (Blue Cross Blue Shield of Florida SMTP Relay(WSS) v3.2 SR1); Thu, 28 Oct 99 09:43: 02 -0400 X-Server-Uuid: 1f3d01f6-3236-11d2-8b2f-00c04f971bc8 X-Server-Uuid: 25439fb6-7579-11d1-978b-00a024cc3d5c From: "Ward, Jon" To: "'BJUENEMAN@novell.com'" , cc: Subject: RE: S-MIME key length Date: Thu, 28 Oct 1999 09:41:41 -0400 MIME-Version: 1.0 X-WSS-ID: 14068D1526466-01-02 X-WSS-ID: 14068D6C117060-01-02 X-WSS-ID: 14068D1B39989-01-02 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF214A.3092B722" Message-ID: <14068D1B39989-01@Blue_Cross_Blue_Shield_of_Florida> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF214A.3092B722 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit We, at Blue Cross, are using an SMTP relay with a combined S/MIME Proxy that stores certificates, performs the encryption, signing, decryption and validation of signatures at the proxy as the messages pass the proverbial gate. It attaches an explanation of the message's security status to incoming messages. I have attached the "alert" file itself as an example. It explains that the certificate was not verifiable because we don't trust Novell's root certificate yet. So, we are eating our own dog food, and are not facing a significant obstacle with 2048 bit keys. We will trust the root certificate and monitor the status of new, incoming, signed messages. Further bulletins will follow as events warrant. Jon Ward Senior Systems Analyst/Messaging Architecture Blue Cross Blue Shield of Florida Voice: +1 (904) 791-6057 Jon.Ward@bcbsfl.com -----Original Message----- From: BJUENEMAN@novell.com [mailto:BJUENEMAN@novell.com] Sent: Wednesday, October 27, 1999 7:20 PM To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ietf-smime@imc.org Subject: Re: S-MIME key length And your signed message causes GroupWise to say, effectively, that "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person as the "dennis.glatting@software-munitions.com" that was issued a VeriSign certificate. But did Communicator complain because you don't haven't added the Novell root certificate to your cache of trusted roots, or because your incoming mail processor modified the contents somehow, or was there some other kind of problem? And BTW, Has anyone notied the irony of having these kinds of problem on this list? Maybe we should all start eating our own dog food, and actually use the stuff we're building, on this list in particular? This is signed with a 1024 bit key, using the same root certificate, which however uses a 2048 bit key. Bob >>> Dennis Glatting 10/27/99 03:34PM >>> BJUENEMAN@novell.com wrote: > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > who hasn't been able to validate the signature with that length key. Encryption > could conceivably be a different issue, depending on whether or not a recipient > is constrained by export and/or import policy. > Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". ------_=_NextPart_000_01BF214A.3092B722 Content-Type: text/plain; charset=us-ascii; name=wssalert.txt Content-Disposition: attachment; filename=wssalert.txt Content-Transfer-Encoding: 7bit "Blue Cross Blue Shield of Florida" made the following annotations on 10/27/99 13:05:06 ------------------------------------------------------------------------------ [ALERT] -- Security Manager: Message security properties: Encrypted: No Signed by Sender: Unknown Contents Altered after signing: No Signature Algorithm: SHA1 The message encryption and/or signature are unacceptable for the following reasons: The signing certificate is not associated with the sender of the message. The signing certificate is either not valid or not trusted. ============================================================================== ------_=_NextPart_000_01BF214A.3092B722-- Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23492 for ietf-smime-bks; Wed, 27 Oct 1999 19:38:34 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23486 for ; Wed, 27 Oct 1999 19:38:33 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id TAA02827; Wed, 27 Oct 1999 19:39:22 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <3817B75A.9EF81AA7@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 19:39:22 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Hayes CC: BJUENEMAN@novell.com, ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272318.QAA17061@ns.secondary.com> <381790DE.C4E0EACC@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Terry Hayes wrote: > > Thanks Bob, > > Dennis' message appears invalid to me (Communicator) for > the same reason you give. And yours is invalid because it's > issued by Novell, which I don't trust (yet?). > My NS reader says your signature is good. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23403 for ietf-smime-bks; Wed, 27 Oct 1999 19:35:11 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23399 for ; Wed, 27 Oct 1999 19:35:10 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id TAA02814; Wed, 27 Oct 1999 19:37:47 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <3817B6FB.BE32E40E@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 19:37:47 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272320.QAA01392@btw.plaintalk.bellevue.wa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: BJUENEMAN@novell.com wrote: > > And your signed message causes GroupWise to say, effectively, that > "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person > as the "dennis.glatting@software-munitions.com" that was issued a > VeriSign certificate. > Damn. I thought I changed my cert. Obviously I did not. I will fix that. > But did Communicator complain because you don't haven't added the > Novell root certificate to your cache of trusted roots, or because your > incoming mail processor modified the contents somehow, or was > there some other kind of problem? > I did not add a Novell root cert. However, NS says there is a "NOVELL EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read your messages I notice your cert listed in "Other People's Certificates." I can add that cert but I don't that that is your point, is it? It's possible my mail tool modified the input. I am working on my mail environment, turning off my NeXTSTEP machines, using different mail tools, adding TLS to secure IMAP transport -- generally having fun. When I click on the Invalid Signature icon associated with your messages NS displays: The Certificate that was used to digitally sign this message is invalid. The error was: The certificate issuer for this server has been marked as not trusted by the user. Netscape refuses to connect to this server. (I did?) This message included the Security Certificate for BJueneman. To check the Certificate or edit Certificate Trust Information, press the ``View/Edit'' button. This Certificate has automatically been added to your list of People's Certificates to make it possible for you to send secure mail to this person. What do you suggest I do? > And BTW, Has anyone notied the irony of having these kinds of problem > on this list? Maybe we should all start eating our own dog food, and > actually use the stuff we're building, on this list in particular? > Sure. I'm game. Though I have done much reading on PK standards and read various other books over the years I haven't really used the technologies, mostly due to stupid vendor implementations (my favorite is buying a "recently released" package in May of 1999 that wasn't Y2K compliant and required me to downgrade the NT server to a non-Y2K version), compatibility issues, implementation issues, licensing issues, etc. So, since I am between projects and have time on my hands, to use your own words, I'm eating my own dog food. :) > This is signed with a 1024 bit key, using the same root certificate, > which however uses a 2048 bit key. > Let's resolve this issue off-line. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17590 for ietf-smime-bks; Wed, 27 Oct 1999 16:52:46 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17585 for ; Wed, 27 Oct 1999 16:52:45 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA20034 for ; Wed, 27 Oct 1999 16:55:19 -0700 (PDT) Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FKAD4L00.RN8; Wed, 27 Oct 1999 16:55:33 -0700 Message-ID: <381790DE.C4E0EACC@netscape.com> Date: Wed, 27 Oct 1999 16:55:10 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: dennis.glatting@plaintalk.bellevue.wa.us, ietf-smime@imc.org Subject: Re: S-MIME key length References: <199910272318.QAA17061@ns.secondary.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms98CFEB9A6CFBEDC9357B9F0C" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms98CFEB9A6CFBEDC9357B9F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Bob, Dennis' message appears invalid to me (Communicator) for the same reason you give. And yours is invalid because it's issued by Novell, which I don't trust (yet?). Yes, I find it amusing that there are complaints about perfectly valid S/MIME messages on this list. You would think this would be one of the few places that you could send signed messages without worrying about confusing the person at the other end. Terry BJUENEMAN@novell.com wrote: > And your signed message causes GroupWise to say, effectively, that > "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person > as the "dennis.glatting@software-munitions.com" that was issued a VeriSign > certificate. > > But did Communicator complain because you don't haven't added the > Novell root certificate to your cache of trusted roots, or because your > incoming mail processor modified the contents somehow, or was > there some other kind of problem? > > And BTW, Has anyone notied the irony of having these kinds of problem > on this list? Maybe we should all start eating our own dog food, and > actually use the stuff we're building, on this list in particular? > > This is signed with a 1024 bit key, using the same root certificate, which > however uses a 2048 bit key. > > Bob > > >>> Dennis Glatting 10/27/99 03:34PM >>> > BJUENEMAN@novell.com wrote: > > > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > > who hasn't been able to validate the signature with that length key. Encryption > > could conceivably be a different issue, depending on whether or not a recipient > > is constrained by export and/or import policy. > > > > Funny you should mention that. When I clicked to read your message my > Netscape 4.61 Communicator displays an icon stating "Invalid > Signature". --------------ms98CFEB9A6CFBEDC9357B9F0C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAAAAAA AACgggk0MIIC2DCCAkGgAwIBAgICDXwwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTkxMDE0MTY1MzQ5WhcNMDAwNDExMTY1 MzQ5WjCBgTETMBEGCgmSJomT8ixkARkWA2NvbTEYMBYGCgmSJomT8ixkARkWCG5ldHNjYXBl MSIwIAYJKoZIhvcNAQkBFhN0aGF5ZXNAbmV0c2NhcGUuY29tMRQwEgYDVQQDEwtUZXJyeSBI YXllczEWMBQGCgmSJomT8ixkAQETBnRoYXllczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA1s8GICPyR1kQqA7mGRxdCi21lINNAmaSfR8y8gztgiEs62usFTxN3n3SeEuJ98G0eGe2 YYrFLOH184Y5ASEa/SBqakbBptQvX2/u+iuFlPksYOG2p+iYNMSZrfZWFkHfaNaVWTcEOpgf 9zhOulQi7QAQS6flGkiZdIfTa2TudpUCAwEAAaNLMEkwDwYDVR0PAQH/BAUDAweAADA2Bggr BgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0G CSqGSIb3DQEBBAUAA4GBABOS1W/NATBPFkABX3iOReoTX6GA9rbpRIk/ldB12X1Rtb9OyW+v xPsGJY+uaxqOd/HBNegVuTmceBgIIY2yJS0hYMU2+jceeX58CFw+sLfsBDhqjHGV09BosrvV jh8JUGoZCCXYHhKmQT9T6Z7WHac4daUmlDC6VlZTwz50BP/2MIIDRTCCAq6gAwIBAgIBJzAN BgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZ EarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB /AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNV HSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/ QbQHCDkMIfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDV Yjtw1Q6xZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqB DSmOneQPMwuPjSQ97DCCAwswggJ0oAMCAQICAg17MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYD VQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoT EkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UE AxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk5MTAxNDE2NTM0OVoXDTAw MDQxMTE2NTM0OVowgYExEzARBgoJkiaJk/IsZAEZFgNjb20xGDAWBgoJkiaJk/IsZAEZFghu ZXRzY2FwZTEiMCAGCSqGSIb3DQEJARYTdGhheWVzQG5ldHNjYXBlLmNvbTEUMBIGA1UEAxML VGVycnkgSGF5ZXMxFjAUBgoJkiaJk/IsZAEBEwZ0aGF5ZXMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAM6wWpjQcG/jYOKlYe4KJTGzFh+MD3RD5d/MIOt6a0/fUC7zS1FOl4fisUH4 SyWKhFY5cmIlQfhnSyyEyibktAf20h09GcPdIc5RnV8Spwngc3FhRnT0/gQS+Lz/Q1T777Rl gqZrcBbAWRx7tgLkpWYd9OanZGXqSYxlNestTP8PAgMBAAGjfjB8MA4GA1UdDwEB/wQEAwIF IDARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUojtlMvf3G4n8VQ0HAbyHSFr9kD0w NgYIKwYBBQUHAQEEKjAoMCYGCCsGAQUFBzABhhpodHRwOi8vbnNvY3NwLm5ldHNjYXBlLmNv bTANBgkqhkiG9w0BAQQFAAOBgQDQGuP8NV5Mn5m5jIzMMy4GQh3km10XnG5xicU5X6CWFjrf irkhxJWrK6UdN5Txpwums9UAj5kp/HkFenUgVuoCqiezvTEDLvZLmqbnCxOPY2xqIr/hjD6R FImDJklzb52sb0HTgFuHW7fGKX+PYeeIPwQE5PJRzw9sgnN3xrGBMjGCAfUwggHxAgEBMIGa MIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcx GzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2ll czEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgINfDAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAy NzIzNTUxM1owIwYJKoZIhvcNAQkEMRYEFFyuYvxBCYorLwrGaYg922O5buVxMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGALpqAwEuIsfZFfITISrx6 2p0RbcHE1qNNrp/JRzyAuiai5Ubh1CCNLfmQeEu5sHiEpx12KMFgp31UDS9UiN1WxktUQOtz yk3VG7eCFLM30OR8cBK/8w+38YxThhO+QI9i7gA0DaJ04i37KjsEIa6W7uImrjWX5fJ4mv3X 80r1dGwAAAAAAAA= --------------ms98CFEB9A6CFBEDC9357B9F0C-- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA17499 for ietf-smime-bks; Wed, 27 Oct 1999 16:47:17 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17495 for ; Wed, 27 Oct 1999 16:47:16 -0700 (PDT) Message-Id: <4.2.1.19991027164628.00c01cd0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 16:50:49 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: S-MIME key length In-Reply-To: <199910272318.QAA17061@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:20 PM 10/27/99 -0600, BJUENEMAN@novell.com wrote: >Maybe we should all start eating our own dog food, and >actually use the stuff we're building, on this list in particular? This list is for developing the S/MIME protocol, not for developing S/MIME applications. There's a big difference. Many people are on this list to follow CMS issues that have nothing to do with S/MIME MUAs. I think it's inappropriate to burden them with experiments in interoperability that have nothing to do with the protocol. If people want, I'd be happy to set up an S/MIME developer's list for issues and testing such as this. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17067 for ietf-smime-bks; Wed, 27 Oct 1999 16:18:12 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA17061 for ; Wed, 27 Oct 1999 16:18:10 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910272318.QAA17061@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 17:20:42 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 17:20:00 -0600 X-Mailer: Groupwise 5.5.2.1 Cc: ietf-smime@imc.org Subject: Re: S-MIME key length To: dennis.glatting@plaintalk.bellevue.wa.us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____TDAUBBZBTADSZSVVWNHS____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____TDAUBBZBTADSZSVVWNHS____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable And your signed message causes GroupWise to say, effectively, that=20 "dennis.glatting@plaintalk.bellevue.wa.us" is not the same person=20 as the "dennis.glatting@software-munitions.com" that was issued a VeriSign certificate. But did Communicator complain because you don't haven't added the=20 Novell root certificate to your cache of trusted roots, or because your=20 incoming mail processor modified the contents somehow, or was=20 there some other kind of problem? And BTW, Has anyone notied the irony of having these kinds of problem=20 on this list? Maybe we should all start eating our own dog food, and=20 actually use the stuff we're building, on this list in particular? This is signed with a 1024 bit key, using the same root certificate, = which=20 however uses a 2048 bit key. Bob >>> Dennis Glatting 10/27/99 = 03:34PM >>> BJUENEMAN@novell.com wrote: >=20 > This message is signed with a 2048 bit key. So far, I haven't encountere= d anyone > who hasn't been able to validate the signature with that length key. = Encryption > could conceivably be a different issue, depending on whether or not a = recipient > is constrained by export and/or import policy. >=20 Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". --____TDAUBBZBTADSZSVVWNHS____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature MIIKxwYJKoZIhvcNAQcCoIIKuDCCCrQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCZsw ggSLMIIDc6ADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgIEZjANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTgxMzAwWhcNMDExMDA5MTgxMzAwWjBCMRIwEAYDVQQDEwlCSnVlbmVtYW4xDTALBgNVBAsT BE5TUkQxDDAKBgNVBAsTA1BSVjEPMA0GA1UEChMGTm92ZWxsMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDtQOLi4Nh63hmnOho34etELuNr/OlosQ8ApPHkOH4C8al+DM02r8tCC3UwP5Dr1/35 mK9vJadCypt1DW9j0FDIx6v/nCfK92Iyp1zRuWxu4dIigERLn9L+qJCld2rFHSGEUKQNFN6enV35 M4TDYErBotXKmZsrAZFLCLgafhYmRQIDAQABo4ICBTCCAgEwDAYDVR0jBAUwA4ABATAiBgNVHREB AQAEGDAWgRRCSlVFTkVNQU5Abm92ZWxsLmNvbTCCAcsGC2CGSAGG+DcBCQQBAQEABIIBtzCCAbME AgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVsb3Blci5u b3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCCAUSgGgEB ADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaIGAgEU AQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAIIf/// //////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBSoVICAQICAgD/AgEAAw0A QAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEBAAIBFDAVMBACAQACCH// ////////AQEAAgEUok4wTAIBAgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADASMBAC AQACCH//////////AQEAMBIwEAIBAAIIf/////////8BAQAwDQYJKoZIhvcNAQEFBQADggEBACgd u//Y7A8xnyLYzcmAjTYs5O6xx8QUkglVIRRC/E/a1NfI0xgscfO4x98mzDBM32rAJRdzsQGiyLHC LsE+zuzMmiF0L5yH8hUG+zWX64zRovvz+b6vELBeE3g9Otc8dO+CoVAqMiIE2zPtatuBO9bRgvt9 0fzVX/mGG5LZMs3wJYlP0rYwl/PryiFLdYTvY60+vdShFM4l6RZD3h0mtXzFUFzKBCukJo+98ACX MAi9/kcR5KtnjGzgyCaCwbS5fYs5AOElxIYFQL5Ht/SMMDWoKdEFkPC8WPjJf9BFVHbLk0fOt0fm iPPEhAsmZW/jngoKq85dGQ+WnMJYZDM/6cYwggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCa d8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkxMDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRsw GQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ56dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jE ILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEULmf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8no S3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8+ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8 em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoibkSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8 WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNIFmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGj ggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSMEBTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0P AQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1 cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9y eS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQEC AQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEA Aw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBAC AQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAA AAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/////////8BAQACARSiTjBMAgEC AgIA/wIBAAMNAID//////////////wMJAID/////////MBIwEAIBAAIIf/////////8BAf8wEjAQ AgEAAgh//////////wEB/zANBgkqhkiG9w0BAQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4 f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0Sxj69kL7mlqowVlU6dgoEPgqwPglP0jBO60Eyzqjo rrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/iurILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B 0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5A ECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4 P8vAinCxJTGB9TCB8gIBATBQMDIxGzAZBgNVBAsTEk5vdmVsbCBFbXBsb3llZSBDQTETMBEGA1UE ChQKTk9WRUxMX0lOQwIaAhQAAAAUNP1e8mQuJK2QmnfLPCP/cgICBGYwCQYFKw4DAhoFADANBgkq hkiG9w0BAQEFAASBgJ0J44QK3D4ET/l4DT978e6+4ImBlE3ELJVPKVFzbopu3uxc58OdSTpOuwvg E3m77J9SWZFQdLg5z7yRZZgjrkjEoVyboN4zTFiDj+krJKH8abOH/1XOW+xGxo6tSCdO1M6PWd20 MFm7A9tmnMUp1E5tNXgIvVZiKe0w3xcp4oyP --____TDAUBBZBTADSZSVVWNHS____-- Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16152 for ietf-smime-bks; Wed, 27 Oct 1999 15:49:08 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16147 for ; Wed, 27 Oct 1999 15:49:07 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id SAA28624 for ; Wed, 27 Oct 1999 18:52:39 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id SAA28620 for ; Wed, 27 Oct 1999 18:52:39 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id SAA12374 for ; Wed, 27 Oct 1999 18:52:00 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id SAA08307 for ; Wed, 27 Oct 1999 18:48:32 -0400 (EDT) Message-Id: <199910272248.SAA08307@ara.missi.ncsc.mil> Date: Wed, 27 Oct 1999 18:48:32 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: giLQL6wd2OliyN9c4Ds6Tg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Date: Mon, 25 Oct 1999 09:09:17 -0700 > From: Paul Hoffman / IMC > > Disagree. We are far from understanding how certificates are and will be > published. LDAP certificate retrieval is well-defined, but not yet widely > implemented, particularly for S/MIME MUAs. Ignoring for now the issue of alternatives to LDAP, do you agree with my proposal -- namely, that in the case where LDAP *is* used to carry the SMimeCertificatePublish object, the certificates field shall be empty? Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA14766 for ietf-smime-bks; Wed, 27 Oct 1999 14:32:26 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14762 for ; Wed, 27 Oct 1999 14:32:18 -0700 (PDT) Received: from plaintalk.bellevue.wa.us (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id OAA00602; Wed, 27 Oct 1999 14:34:44 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be plaintalk.bellevue.wa.us Message-ID: <38176FEB.574F61D@plaintalk.bellevue.wa.us> Date: Wed, 27 Oct 1999 14:34:35 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BJUENEMAN@novell.com CC: ietf-smime@imc.org, V KRISHNA REDDY Subject: Re: S-MIME key length References: <199910271533.IAA07337@ns.secondary.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms967F7AD330FECC810CCC2CB0" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms967F7AD330FECC810CCC2CB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit BJUENEMAN@novell.com wrote: > > This message is signed with a 2048 bit key. So far, I haven't encountered anyone > who hasn't been able to validate the signature with that length key. Encryption > could conceivably be a different issue, depending on whether or not a recipient > is constrained by export and/or import policy. > Funny you should mention that. When I clicked to read your message my Netscape 4.61 Communicator displays an icon stating "Invalid Signature". --------------ms967F7AD330FECC810CCC2CB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKLgYJKoZIhvcNAQcCoIIKHzCCChsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B7owggSEMIID7aADAgECAhAV4oOYVg1pE0gVFzzXJ4WbMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDMyMTAwMDAw MFoXDTAwMDMyMDIzNTk1OVowggEoMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0Rlbm5pcyBHbGF0dGluZzE1MDMGCSqG SIb3DQEJARYmZGVubmlzLmdsYXR0aW5nQHNvZnR3YXJlLW11bml0aW9ucy5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKSBSrAz19P5zPsu3odv359aq1FIuU7RXSXlVga0DqpE ST8T6/e3wtn1f8NnfnytpCWP4r2FgO51Z2Q8o5fy99Gajtlm5tYDBEm09HGWoxAYfEJE8oVI lMCDRQazW5WFiY8WkoNl36eoVl0Oa5rsaSMnk5u45R7Mu3wyLRBooXfnAgMBAAGjggEGMIIB AjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVy aVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2Ug bGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B AQQFAAOBgQAlb2LpvHzHBF/o/uILYbM2MGnIkf4y7PN+XQnMAXpk1mIFeVtIH+kquwCo93ra 9h1wdohBxmPt4Sw/EHG4WNr8PnYXuo7kFOBokqSTOYQTr/6zbSKnjXhO3N4qWKoS0dK0G8GO QTKulULvZBkmbnHJ1YIvES2KH7hC2Uzs1K7SDDCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKo JV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgT Vi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMC AQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0G CSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVq D7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9d WBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEBXig5hWDWkTSBUX PNcnhZswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw05OTEwMjcyMTM0MzVaMCMGCSqGSIb3DQEJBDEWBBTJWx1/ew/mu+iRtbjKaPN/ /iESjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgIye 4H0KwvUxoYqZZtHM44gCRyp6DyV3AceT7OgvbicFwDc7t1IrfwR7dBmTb3xmCVwAG04gOdhE v7BQk0J+vpLzNh/zwDoCYWRuEv1QfE0+pAjZ/jICI/VNQ9/mYNzMLntMcMszxF9dm0Y2ETZ6 nrCBHA7zo+zuNFouac+M8sDV --------------ms967F7AD330FECC810CCC2CB0-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA09204 for ietf-smime-bks; Wed, 27 Oct 1999 09:39:05 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA09200 for ; Wed, 27 Oct 1999 09:39:04 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910271639.JAA09200@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 10:41:05 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 10:41:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____WADBJNCIRFTLTXQWWZIG____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____WADBJNCIRFTLTXQWWZIG____ Content-Type: multipart/mixed; boundary="____RXPVIHJZACUBDQYIVIQA____" --____RXPVIHJZACUBDQYIVIQA____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Apparently there are people on the list who don't have S/MIME compliant readers, and I accidentally used base64 encoding. Here is the message in clear text form. Bob I'm afraid I strongly disagree with Paul and Rik, and=20 agree with Bartlett and David Kemp instead. I'm speaking as an architect who is responsible for defining our future direction with respect to our GroupWise S/MIME V3 implementation, in addition to our PKI product line, including=20 the Novell Certificate Server 2.0 (which was released just hours ago as a FREE web release -- see=20 http://www.novell.com/press/archive/1999/10/pr99130.html),=20 as well as our LDAP direction in this space. I believe that providing multiple "standard" ways of doing=20 something that is relatively simple inevitably leads to=20 unnecessary duplication of effort, and more importantly, serious interoperability problems between vendors. It's difficult enough to get multiple vendors to do something right when there is only one way to do it. If there are multiple options, as with the current logic for determining what encryption algorithm to use, someone is bound to screw it up, with the result that two different products have difficulty communicating. If I could turn the clock back a year or two, I would have preferred=20 that the SMIME Capabilities attribute be included in the end-user's certificate directly. Failing that, I would have liked to see a "Capabilities" certificate = that=20 is issued and signed by the end-user herself, that in addition to = containing SMIME stuff regarding what algorithms were supported, might also have contained the equivalent of a CPS statement that defends=20 the user, and not just the CA, from unwanted reliance on a signature, for example. If the end-user published such a certificate, it would have = made=20 sense to put it in the same LDAP bucket as the end-user's own certificate. Both of those options are probably foreclosed by now, unfortunately, so we are left with the problem of where to put the SMIME Capabilities, = and where to put the user's S/MIME certificates. With respect to the certificates themselves, I don't think there is any=20 question at all -- all, or nearly all, of the public CAs and CA toolkit = vendors=20 publish the certificates in the already defined LDAP attributes. And from a certificate management perspective, the last thing that either = the user/system administrator or the vendor wants is to have to manage TWO=20 sets of certificates stored in separate places. The possibilities for = errors are obvious -- one certificate gets deleted/replace, and the other one=20 doesn't, etc. I suppose that it could be argued from an LDAP user's perspective that=20 it might be convenient to be able to browse through a directory, find the desired user, and click on one directory attribute to retrieve the = SMIME=20 Capabilities and the entire certificate chain in one operation. I'm = relatively certain that's the scenario that the authors had in mind for this = capability. However, I don't think that's what will happen in practice. Instead, I expect that an e-mail user will type in or select names from=20 his personal or system address book. Then he or she will decide to=20 encrypt the message, without regard to whether or not all of the certificat= es=20 for all of the addressees have already been cached locally. At that point, the MUA should automatically fetch the certificates and=20 SMIME capabilities for all of the users, and perhaps prompt the user=20 to make sure that those are in fact the right certificates for those = users. But the management of the certificate chain, the SMIME Capabilities, = and=20 any other "plumbing" that the user doesn't absolutely have to be exposed = to=20 should be handled by the MUA. So the retrieval of the end-users certificat= e(s),=20 the CA certificates, and the SMIME Capabilities should all be handled=20 automatically, without user intervention. Since it is software that is = going=20 to be doing the retrieval, and not a human user, retrieving from multiple = attributes is not a problem. >From this perspective, I think it is obvious that there should be one and = only way to store and retrieve such certificates. Otherwise, it will be = necessary=20 to implement both types of directory fetches, just in case, and that just causes more complexity, code bloat, system and interoperability testing, = etc. Yuck! The current way of retrieving certificates is completely adequate, IMHO. If it ain't broke, don't fix it. Bob >>> 10/26/99 10:16AM >>> -----Original Message----- From: phoffman [SMTP:phoffman@imc.org]=20 Sent: Monday, October 25, 1999 5:09 PM To: ietf-smime Cc: phoffman Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving= >certificates, Disagree. We are far from understanding how certificates are and will = be=20 published. LDAP certificate retrieval is well-defined, but not yet = widely=20 implemented, particularly for S/MIME MUAs. [O'Malley, Bartley] =20 Is this sufficient grounds to junk it? If it is not widely implemented = yet=20 because of inherent problems, then fine, but if it is simply due to its=20 newness(my vote) we risk delaying the implementation of either by muddying = the=20 water with the introduction of a second. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we = have=20 so little understanding of S/MIME customer needs, I don't think having = an=20 alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. [O'Malley, Bartley]=20 Pause for a moment... Do you really?(wish that is) If you did, why would you support the introduction of an overlapping = standard. --Paul Hoffman, Director --Internet Mail Consortium --____RXPVIHJZACUBDQYIVIQA____ Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Bob Jueneman.vcf"; modification-date="Wed, 27 Oct 1999 10:37:10 -0600" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US= A LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606=3D0A=3D USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --____RXPVIHJZACUBDQYIVIQA____-- --____WADBJNCIRFTLTXQWWZIG____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBADWOjxnKCxFbFR/v5MyEYjGiwQo3HF9q KfNLZmC7uzeJLuBRMWpYri0MEKvNZmuh89kcfagnx1z5LAGqXtsPuDPOTiIn4GwdNp8r1QG+y9mK HVI4ZCLfZxEFPwkwl5jYNp5sTszzzf96m+PswkckN5BTJl5h/W6jwNs9O2s8xFdWRQ++l5BMuh78 gQcNei8riTayYmTKHILfPLAjNT9cBxrvjs+1A7ccC5mTEbr1jUki18OjsYyzCz8tZZ9q691+t3B7 oHc1mJpKnV7alxj0lNH71ZTXK+A+iK+kPx8grFYHeZkWVDfG6p5AyJyG1DrAkcUpy5voh/1/9R8v qMooLYI= --____WADBJNCIRFTLTXQWWZIG____-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA07341 for ietf-smime-bks; Wed, 27 Oct 1999 08:33:47 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07337 for ; Wed, 27 Oct 1999 08:33:46 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910271533.IAA07337@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Oct 1999 09:35:46 -0600 Mime-Version: 1.0 Date: Wed, 27 Oct 1999 09:35:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: Re: S-MIME key length To: ietf-smime@imc.org, V KRISHNA REDDY Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____ACYPFYRFVBRYBLIJGPKZ____" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --____ACYPFYRFVBRYBLIJGPKZ____ Content-Type: multipart/mixed; boundary="____ZTOGZPVTRLXLEKEAXCPG____" --____ZTOGZPVTRLXLEKEAXCPG____ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This message is signed with a 2048 bit key. So far, I haven't encountered = anyone who hasn't been able to validate the signature with that length key. = Encryption=20 could conceivably be a different issue, depending on whether or not a = recipient is constrained by export and/or import policy. We've done some limited testing with "odd-ball" key lengths -- 768, and = even odd number such as 1027, etc. No observed problems. Doesn't guarantee that everyone's software will handle such keys, of course. Bob Robert R. Jueneman Security Architect Network Security Development Novell, Inc. 122 East 1700 South Provo, UT 84606 bjueneman@novell.com 1-801-861-7387 DISCLAIMER: If this message (with or without attached documents) is digitally = signed, and/or if certificates are attached, the intended purpose is to=20 (1) Ensure that e-mail came from the apparent sender (2) Protect e-mail from tampering (3) Ensure that the content of e-mail sent to me and encrypted in my = dual-use key cannot be viewed by others. It is explicitly NOT the intent of any such signed message or document = to represent any type or form of legally binding contract or other = representation, and any such interpretation should not be considered = commercially reasonable and WILL BE REPUDIATED, notwithstanding any = wording or implications to the opposite effect in the text of the message = itself; due in part, but not exclusively, to the fact that the security of = my workstation and its associated cryptography is not judged adequately = strong for such purposes at present. >>> Bruce Greenblatt 10/26/99 = 09:32PM >>> As I understand it, the S/MIME spec lets you use any key length that you want, as long as you have an algorithm OID for it... So, you can definitely use 1024 bit keys. At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: >I want the information whether s-mime specification gives us the >flexibilty to use 1024 bit key length.Actually what is the status of the >specification regarding key length. >--krishna=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --____ZTOGZPVTRLXLEKEAXCPG____ Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Bob Jueneman.vcf"; modification-date="Wed, 27 Oct 1999 09:35:30 -0600" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US= A LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606=3D0A=3D USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. = Jueneman=3D0A=3D PRV-F331=3D0A=3D 122 E. 1700 South=3D0A=3D Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --____ZTOGZPVTRLXLEKEAXCPG____-- --____ACYPFYRFVBRYBLIJGPKZ____ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" CONTENT-DESCRIPTION: S/MIME Cryptographic Signature MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5 6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8 +ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/ ////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl 8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN 1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669 GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo 4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5 y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh///// /////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf/// //////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93 aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBAEatjb80kubAXhf8bJ3/mHVNDN/KrK2O SuN2GqMik1ux3EASie9K9MjnKVdZ5ec5HbW4I3GlWZkoplIgpY8nnjRgvC7yktw2UJqx2DaAN58d b8hs64UDzF4saCPPWQySWz3yH57ITxYNPBtgpcbp4rNdpf04EgNQSxS04cLXZvFX0hL1teSz00Un tJJeUNb/cUH9/ckjODFPfcDzO3W/P0acpDWQUjM6Vy3m28aVK/mHjFAZEmCq8BrjVROOuLOAwebh ij0TuxCo7YsRIDnKLeeklNUmBM+1dP9xyZHe5K1W+KJSd3+4VmBHfyASV6Zk4SSGkJmG3SdDhvWI ume36Yg= --____ACYPFYRFVBRYBLIJGPKZ____-- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06546 for ietf-smime-bks; Wed, 27 Oct 1999 07:55:34 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06541 for ; Wed, 27 Oct 1999 07:55:32 -0700 (PDT) Message-Id: <4.2.1.19991027075837.00ccdc20@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 07:59:06 -0700 To: From: Paul Hoffman / IMC Subject: Re: s/mime certificate format In-Reply-To: <00c101bf206f$a6535100$091010ac@venky.cmcltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:07 PM 10/27/99 +0530, krishna Reddy wrote: >Can you plese give the S/MIME v3 certificate format.What are the field >extensions that are necessary for such a certificate. All the RFCs are available from the WG's web site at . --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id FAA02730 for ietf-smime-bks; Wed, 27 Oct 1999 05:45:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02724 for ; Wed, 27 Oct 1999 05:45:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09319; Wed, 27 Oct 1999 08:48:53 -0400 (EDT) Message-Id: <199910271248.IAA09319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-ecc-00.txt Date: Wed, 27 Oct 1999 08:48:53 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Elliptic Curve S/MIME Author(s) : P. Lambert Filename : draft-ietf-smime-ecc-00.txt Pages : Date : 26-Oct-99 This document is the first draft of a profile for the incorporation of Elliptic Curve (EC) public key algorithms in the Cryptographic Message Syntax (CMS). The EC algorithms support the creation of digital signatures and the distribution of keys to encrypt or authen- ticate message content. The definition of the algorithm processing is based on the ANSI X9.63 draft, developed by the ANSI X9F1 working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-ecc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-ecc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991026150244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-ecc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-ecc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026150244.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA01353 for ietf-smime-bks; Wed, 27 Oct 1999 04:34:35 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01331 for ; Wed, 27 Oct 1999 04:33:59 -0700 (PDT) Received: from venky.cmcltd.com ([172.16.16.9]) by cmcltd.com (8.8.7/8.8.7) with SMTP id SAA13845 for ; Wed, 27 Oct 1999 18:03:39 +0530 Message-ID: <00c101bf206f$a6535100$091010ac@venky.cmcltd.com> From: "krishna Reddy" To: Subject: s/mime certificate format Date: Wed, 27 Oct 1999 17:07:27 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01BF209D.BF176900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01BF209D.BF176900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can you plese give the S/MIME v3 certificate format.What are the field = extensions that are necessary for such a certificate. --krishna ------=_NextPart_000_00BE_01BF209D.BF176900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can you plese give the S/MIME v3 = certificate=20 format.What are the field extensions that are necessary for such a=20 certificate.
--krishna
------=_NextPart_000_00BE_01BF209D.BF176900-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA00756 for ietf-smime-bks; Wed, 27 Oct 1999 04:04:08 -0700 (PDT) Received: from mta1.lkp.frontec.se (pc254.frontec.se [193.13.194.254]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA00752 for ; Wed, 27 Oct 1999 04:04:04 -0700 (PDT) From: Andreas.Rehn@sth.frontec.se Received: by mta1.lkp.frontec.se(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 80256817.00422ED3 ; Wed, 27 Oct 1999 13:02:53 +0100 X-Lotus-FromDomain: FRONTEC To: ietf-smime@imc.org Message-ID: <80256817.00422E00.00@mta1.lkp.frontec.se> Date: Wed, 27 Oct 1999 13:11:37 +0100 Subject: Problem with signatures Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi I am trying to compose S/MIME messages with signed and encrypted data. My question is: what exactly is the input for the signing procedure? For example(below), should all the pkcs#7-mime headers(and the blank lines) be included when the signature is calculated or is it only the base 64 encrypted data? When this example is opened in Netscape Messenger the decryption works fine but the signature is invalid, I am quite sure that I use the right certificates. please advise Andreas Rehn Message-ID: <941020533@random-pc> Date: Wednesday, 27/10/1999 12:35:33 +0200 From: Anders.Jalm@sth.frontec.se To: Anders.Jalm@sth.frontec.se Subject: encrypted to be signed MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="BOUNDARY" --BOUNDARY Content-Type: application/pkcs7-mime; name="test" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb... ... ...qVSnAAAAAA== --BOUNDARY Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3D... ...UB2KZ9RcTbkAAAAAA== --BOUNDARY-- . Received: by ns.secondary.com (8.9.3/8.9.3) id XAA22964 for ietf-smime-bks; Tue, 26 Oct 1999 23:28:15 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA22958 for ; Tue, 26 Oct 1999 23:28:05 -0700 (PDT) Received: from localhost (kris@localhost) by cmcltd.com (8.8.7/8.8.7) with ESMTP id MAA29392; Wed, 27 Oct 1999 12:55:20 +0530 Date: Wed, 27 Oct 1999 12:55:20 +0530 (IST) From: V KRISHNA REDDY To: Bruce Greenblatt cc: ietf-smime@imc.org Subject: Re: S-MIME key length In-Reply-To: <3.0.5.32.19991026203235.0091b480@pop.walltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Can you please send me the format for the S/MIME v3 certificates.i.e. I want to have the all the required fields in the smime v3 certificates. --krishna. On Tue, 26 Oct 1999, Bruce Greenblatt wrote: > As I understand it, the S/MIME spec lets you use any key length that you > want, as long as you have an algorithm OID for it... So, you can > definitely use 1024 bit keys. > > At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: > >I want the information whether s-mime specification gives us the > >flexibilty to use 1024 bit key length.Actually what is the status of the > >specification regarding key length. > >--krishna > > > > > > > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com > Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17315 for ietf-smime-bks; Tue, 26 Oct 1999 20:31:25 -0700 (PDT) Received: from smtp1.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17310 for ; Tue, 26 Oct 1999 20:31:24 -0700 (PDT) Received: from dtasi1 (user38.sj.dialup.innetix.com [209.172.68.101]) by smtp1.walltech.com (8.8.7/8.8.7/walltech-1.28h) with SMTP id UAA09067; Tue, 26 Oct 1999 20:34:04 -0700 (PDT) Message-Id: <3.0.5.32.19991026203235.0091b480@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 26 Oct 1999 20:32:35 -0700 To: V KRISHNA REDDY , ietf-smime@imc.org From: Bruce Greenblatt Subject: Re: S-MIME key length In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As I understand it, the S/MIME spec lets you use any key length that you want, as long as you have an algorithm OID for it... So, you can definitely use 1024 bit keys. At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote: >I want the information whether s-mime specification gives us the >flexibilty to use 1024 bit key length.Actually what is the status of the >specification regarding key length. >--krishna > > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA08052 for ietf-smime-bks; Tue, 26 Oct 1999 16:14:06 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA08048 for ; Tue, 26 Oct 1999 16:14:05 -0700 (PDT) From: BJUENEMAN@novell.com Message-Id: <199910262314.QAA08048@ns.secondary.com> Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 26 Oct 1999 17:16:03 -0600 Mime-Version: 1.0 Date: Tue, 26 Oct 1999 17:15:00 -0600 X-Mailer: Groupwise 5.5.2.1 Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m"; modification-date="Tue, 26 Oct 1999 17:15:56 -0600" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MIIp4QYJKoZIhvcNAQcCoIIp0jCCKc4CAQExCzAJBgUrDgMCGgUAMIIeHAYJKoZIhvcNAQcBoIIe DQSCHglGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUkU6IFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsOmRyYWZ0LWlldGYtc21pbWUtY2VydGRpc3QtMDQudHh0DQpUbzogaWV0Zi1z bWltZUBpbWMub3JnDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9Il9f X19LWkZPSU1QTUZPTURXRkxYV1dLWV9fX18iDQoNCg0KLS1fX19fS1pGT0lNUE1GT01EV0ZMWFdX S1lfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9aXNvLTg4NTktMQ0KQ29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQpJJ20gYWZyYWlkIEkg c3Ryb25nbHkgZGlzYWdyZWUgd2l0aCBQYXVsIGFuZCBSaWssIGFuZD0yMA0KYWdyZWUgd2l0aCBC YXJ0bGV0dCBhbmQgRGF2aWQgS2VtcCBpbnN0ZWFkLg0KDQpJJ20gc3BlYWtpbmcgYXMgYW4gYXJj aGl0ZWN0IHdobyBpcyByZXNwb25zaWJsZSBmb3IgZGVmaW5pbmcgb3VyDQpmdXR1cmUgZGlyZWN0 aW9uIHdpdGggcmVzcGVjdCB0byBvdXIgR3JvdXBXaXNlIFMvTUlNRSBWMw0KaW1wbGVtZW50YXRp b24sIGluIGFkZGl0aW9uIHRvIG91ciBQS0kgcHJvZHVjdCBsaW5lLCBpbmNsdWRpbmc9MjANCnRo ZSBOb3ZlbGwgQ2VydGlmaWNhdGUgU2VydmVyIDIuMCAod2hpY2ggd2FzIHJlbGVhc2VkIGp1c3QN CmhvdXJzIGFnbyAgYXMgYSBGUkVFIHdlYiByZWxlYXNlICAtLSBzZWU9MjANCmh0dHA6Ly93d3cu bm92ZWxsLmNvbS9wcmVzcy9hcmNoaXZlLzE5OTkvMTAvcHI5OTEzMC5odG1sKSw9MjANCmFzIHdl bGwgYXMgb3VyIExEQVAgZGlyZWN0aW9uIGluIHRoaXMgc3BhY2UuDQoNCkkgYmVsaWV2ZSB0aGF0 IHByb3ZpZGluZyBtdWx0aXBsZSAic3RhbmRhcmQiIHdheXMgb2YgZG9pbmc9MjANCnNvbWV0aGlu ZyB0aGF0IGlzIHJlbGF0aXZlbHkgc2ltcGxlIGluZXZpdGFibHkgbGVhZHMgdG89MjANCnVubmVj ZXNzYXJ5IGR1cGxpY2F0aW9uIG9mIGVmZm9ydCwgYW5kIG1vcmUgaW1wb3J0YW50bHksDQpzZXJp b3VzIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgYmV0d2VlbiB2ZW5kb3JzLg0KDQpJdCdzIGRp ZmZpY3VsdCBlbm91Z2ggdG8gZ2V0IG11bHRpcGxlIHZlbmRvcnMgdG8gZG8gc29tZXRoaW5nDQpy aWdodCB3aGVuIHRoZXJlIGlzIG9ubHkgb25lIHdheSB0byBkbyBpdC4gSWYgdGhlcmUgYXJlIG11 bHRpcGxlDQpvcHRpb25zLCBhcyB3aXRoIHRoZSBjdXJyZW50IGxvZ2ljIGZvciBkZXRlcm1pbmlu ZyB3aGF0IGVuY3J5cHRpb24NCmFsZ29yaXRobSB0byB1c2UsIHNvbWVvbmUgaXMgYm91bmQgdG8g c2NyZXcgaXQgdXAsIHdpdGggdGhlDQpyZXN1bHQgdGhhdCB0d28gZGlmZmVyZW50IHByb2R1Y3Rz IGhhdmUgZGlmZmljdWx0eSBjb21tdW5pY2F0aW5nLg0KDQpJZiBJIGNvdWxkIHR1cm4gdGhlIGNs b2NrIGJhY2sgYSB5ZWFyIG9yIHR3bywgSSB3b3VsZCBoYXZlIHByZWZlcnJlZD0yMA0KdGhhdCB0 aGUgU01JTUUgQ2FwYWJpbGl0aWVzIGF0dHJpYnV0ZSBiZSBpbmNsdWRlZCBpbiB0aGUgZW5kLXVz ZXIncw0KY2VydGlmaWNhdGUgZGlyZWN0bHkuDQoNCkZhaWxpbmcgdGhhdCwgSSB3b3VsZCBoYXZl IGxpa2VkIHRvIHNlZSBhICJDYXBhYmlsaXRpZXMiIGNlcnRpZmljYXRlID0NCnRoYXQ9MjANCmlz IGlzc3VlZCBhbmQgc2lnbmVkIGJ5IHRoZSBlbmQtdXNlciBoZXJzZWxmLCB0aGF0IGluIGFkZGl0 aW9uIHRvID0NCmNvbnRhaW5pbmcNClNNSU1FIHN0dWZmIHJlZ2FyZGluZyB3aGF0IGFsZ29yaXRo bXMgd2VyZSBzdXBwb3J0ZWQsIG1pZ2h0DQphbHNvIGhhdmUgY29udGFpbmVkIHRoZSBlcXVpdmFs ZW50IG9mIGEgQ1BTIHN0YXRlbWVudCB0aGF0IGRlZmVuZHM9MjANCnRoZSB1c2VyLCBhbmQgbm90 IGp1c3QgdGhlIENBLCBmcm9tIHVud2FudGVkIHJlbGlhbmNlIG9uIGEgc2lnbmF0dXJlLCBmb3IN CmV4YW1wbGUuICBJZiB0aGUgZW5kLXVzZXIgcHVibGlzaGVkIHN1Y2ggYSBjZXJ0aWZpY2F0ZSwg aXQgd291bGQgaGF2ZSA9DQptYWRlPTIwDQpzZW5zZSB0byBwdXQgaXQgaW4gdGhlIHNhbWUgTERB UCBidWNrZXQgYXMgdGhlIGVuZC11c2VyJ3Mgb3duIGNlcnRpZmljYXRlLg0KDQpCb3RoIG9mIHRo b3NlIG9wdGlvbnMgYXJlIHByb2JhYmx5IGZvcmVjbG9zZWQgYnkgbm93LCB1bmZvcnR1bmF0ZWx5 LA0Kc28gd2UgYXJlIGxlZnQgd2l0aCB0aGUgcHJvYmxlbSBvZiB3aGVyZSB0byBwdXQgdGhlIFNN SU1FIENhcGFiaWxpdGllcywgPQ0KYW5kDQp3aGVyZSB0byBwdXQgdGhlIHVzZXIncyBTL01JTUUg Y2VydGlmaWNhdGVzLg0KDQpXaXRoIHJlc3BlY3QgdG8gdGhlIGNlcnRpZmljYXRlcyB0aGVtc2Vs dmVzLCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueT0yMA0KcXVlc3Rpb24gYXQgYWxsIC0tIGFs bCwgb3IgbmVhcmx5IGFsbCwgb2YgdGhlIHB1YmxpYyBDQXMgYW5kIENBIHRvb2xraXQgPQ0KdmVu ZG9ycz0yMA0KcHVibGlzaCB0aGUgY2VydGlmaWNhdGVzIGluIHRoZSBhbHJlYWR5IGRlZmluZWQg TERBUCBhdHRyaWJ1dGVzLg0KDQpBbmQgZnJvbSBhIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQgcGVy c3BlY3RpdmUsIHRoZSBsYXN0IHRoaW5nIHRoYXQgZWl0aGVyID0NCnRoZQ0KdXNlci9zeXN0ZW0g YWRtaW5pc3RyYXRvciBvciB0aGUgdmVuZG9yIHdhbnRzIGlzIHRvIGhhdmUgdG8gbWFuYWdlIFRX Tz0yMA0Kc2V0cyBvZiBjZXJ0aWZpY2F0ZXMgc3RvcmVkIGluIHNlcGFyYXRlIHBsYWNlcy4gVGhl IHBvc3NpYmlsaXRpZXMgZm9yID0NCmVycm9ycw0KYXJlIG9idmlvdXMgLS0gb25lIGNlcnRpZmlj YXRlIGdldHMgZGVsZXRlZC9yZXBsYWNlLCBhbmQgdGhlIG90aGVyIG9uZT0yMA0KZG9lc24ndCwg ZXRjLg0KDQpJIHN1cHBvc2UgdGhhdCBpdCBjb3VsZCBiZSBhcmd1ZWQgZnJvbSBhbiBMREFQIHVz ZXIncyBwZXJzcGVjdGl2ZSB0aGF0PTIwDQppdCBtaWdodCBiZSBjb252ZW5pZW50IHRvIGJlIGFi bGUgdG8gYnJvd3NlIHRocm91Z2ggYSBkaXJlY3RvcnksIGZpbmQgdGhlDQpkZXNpcmVkIHVzZXIs IGFuZCBjbGljayBvbiBvbmUgZGlyZWN0b3J5IGF0dHJpYnV0ZSB0byByZXRyaWV2ZSB0aGUgPQ0K U01JTUU9MjANCkNhcGFiaWxpdGllcyBhbmQgdGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBjaGFpbiBp biBvbmUgb3BlcmF0aW9uLiAgSSdtID0NCnJlbGF0aXZlbHkNCmNlcnRhaW4gdGhhdCdzIHRoZSBz Y2VuYXJpbyB0aGF0IHRoZSBhdXRob3JzIGhhZCBpbiBtaW5kIGZvciB0aGlzID0NCmNhcGFiaWxp dHkuDQoNCkhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHdoYXQgd2lsbCBoYXBwZW4gaW4g cHJhY3RpY2UuDQoNCkluc3RlYWQsIEkgZXhwZWN0IHRoYXQgYW4gZS1tYWlsIHVzZXIgd2lsbCB0 eXBlIGluIG9yIHNlbGVjdCBuYW1lcyBmcm9tPTIwDQpoaXMgcGVyc29uYWwgb3Igc3lzdGVtIGFk ZHJlc3MgYm9vay4gVGhlbiBoZSBvciBzaGUgd2lsbCBkZWNpZGUgdG89MjANCmVuY3J5cHQgdGhl IG1lc3NhZ2UsIHdpdGhvdXQgcmVnYXJkIHRvIHdoZXRoZXIgb3Igbm90IGFsbCBvZiB0aGUgY2Vy dGlmaWNhdD0NCmVzPTIwDQpmb3IgYWxsIG9mIHRoZSBhZGRyZXNzZWVzIGhhdmUgYWxyZWFkeSBi ZWVuIGNhY2hlZCBsb2NhbGx5Lg0KDQpBdCB0aGF0IHBvaW50LCB0aGUgTVVBIHNob3VsZCBhdXRv bWF0aWNhbGx5IGZldGNoIHRoZSBjZXJ0aWZpY2F0ZXMgYW5kPTIwDQpTTUlNRSBjYXBhYmlsaXRp ZXMgZm9yIGFsbCBvZiB0aGUgdXNlcnMsIGFuZCBwZXJoYXBzIHByb21wdCB0aGUgdXNlcj0yMA0K dG8gbWFrZSBzdXJlIHRoYXQgdGhvc2UgYXJlIGluIGZhY3QgdGhlIHJpZ2h0IGNlcnRpZmljYXRl cyBmb3IgdGhvc2UgPQ0KdXNlcnMuDQoNCkJ1dCB0aGUgbWFuYWdlbWVudCBvZiB0aGUgY2VydGlm aWNhdGUgY2hhaW4sIHRoZSBTTUlNRSBDYXBhYmlsaXRpZXMsID0NCmFuZD0yMA0KYW55IG90aGVy ICJwbHVtYmluZyIgdGhhdCB0aGUgdXNlciBkb2Vzbid0IGFic29sdXRlbHkgaGF2ZSB0byBiZSBl eHBvc2VkID0NCnRvPTIwDQpzaG91bGQgYmUgaGFuZGxlZCBieSB0aGUgTVVBLiAgU28gdGhlIHJl dHJpZXZhbCBvZiB0aGUgZW5kLXVzZXJzIGNlcnRpZmljYXQ9DQplKHMpLD0yMA0KdGhlIENBIGNl cnRpZmljYXRlcywgYW5kIHRoZSBTTUlNRSBDYXBhYmlsaXRpZXMgc2hvdWxkIGFsbCBiZSBoYW5k bGVkPTIwDQphdXRvbWF0aWNhbGx5LCB3aXRob3V0IHVzZXIgaW50ZXJ2ZW50aW9uLiBTaW5jZSBp dCBpcyBzb2Z0d2FyZSB0aGF0IGlzID0NCmdvaW5nPTIwDQp0byBiZSBkb2luZyB0aGUgcmV0cmll dmFsLCBhbmQgbm90IGEgaHVtYW4gdXNlciwgcmV0cmlldmluZyBmcm9tIG11bHRpcGxlID0NCmF0 dHJpYnV0ZXMNCmlzIG5vdCBhIHByb2JsZW0uDQoNCkZyb20gdGhpcyBwZXJzcGVjdGl2ZSwgSSB0 aGluayBpdCBpcyBvYnZpb3VzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSBhbmQgPQ0Kb25seQ0K d2F5IHRvIHN0b3JlIGFuZCByZXRyaWV2ZSBzdWNoIGNlcnRpZmljYXRlcy4gT3RoZXJ3aXNlLCBp dCB3aWxsIGJlID0NCm5lY2Vzc2FyeT0yMA0KdG8gaW1wbGVtZW50IGJvdGggdHlwZXMgb2YgZGly ZWN0b3J5IGZldGNoZXMsIGp1c3QgaW4gY2FzZSwgYW5kIHRoYXQganVzdA0KY2F1c2VzIG1vcmUg Y29tcGxleGl0eSwgY29kZSBibG9hdCwgc3lzdGVtIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Rp bmcsID0NCmV0Yy4NCll1Y2shDQoNClRoZSBjdXJyZW50IHdheSBvZiByZXRyaWV2aW5nIGNlcnRp ZmljYXRlcyBpcyBjb21wbGV0ZWx5IGFkZXF1YXRlLCBJTUhPLg0KSWYgaXQgYWluJ3QgYnJva2Us IGRvbid0IGZpeCBpdC4NCg0KQm9iDQoNCg0KPj4+IDxiYXJ0bGV5Lm8nbWFsbGV5QGNpdGljb3Jw LmNvbT4gMTAvMjYvOTkgMTA6MTZBTSA+Pj4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogcGhvZmZtYW4gW1NNVFA6cGhvZmZtYW5AaW1jLm9yZ109MjANClNlbnQ6IE1vbmRh eSwgT2N0b2JlciAyNSwgMTk5OSA1OjA5IFBNDQpUbzogaWV0Zi1zbWltZQ0KQ2M6IHBob2ZmbWFu DQpTdWJqZWN0OiBSZTogV29ya2luZyBHcm91cCBMYXN0IENhbGw6ZHJhZnQtaWV0Zi1zbWltZS1j ZXJ0ZGlzdC0wNC50eHQNCg0KQXQgMDk6NTEgQU0gMTAvMjUvOTkgLTA0MDAsIERhdmlkIFAuIEtl bXAgd3JvdGU6DQo+U2luY2UgTERBUCBkaXJlY3RvcmllcyBoYXZlIGJvdGggdXNlciBhbmQgQ0Eg Y2VydGlmaWNhdGUgYXR0cmlidXRlcywNCg0KQWdyZWUuDQoNCj5hbmQgTERBUCBpcyB0aGUgSW50 ZXJuZXQgbWVjaGFuaXNtIG9mIGNob2ljZSBmb3IgcHVibGlzaGluZyBhbmQgcmV0cmlldmluZz0N Cg0KPmNlcnRpZmljYXRlcywNCg0KRGlzYWdyZWUuIFdlIGFyZSBmYXIgZnJvbSB1bmRlcnN0YW5k aW5nIGhvdyBjZXJ0aWZpY2F0ZXMgYXJlIGFuZCB3aWxsID0NCmJlPTIwDQpwdWJsaXNoZWQuIExE QVAgY2VydGlmaWNhdGUgcmV0cmlldmFsIGlzIHdlbGwtZGVmaW5lZCwgYnV0IG5vdCB5ZXQgPQ0K d2lkZWx5PTIwDQppbXBsZW1lbnRlZCwgcGFydGljdWxhcmx5IGZvciBTL01JTUUgTVVBcy4NCltP J01hbGxleSwgQmFydGxleV0gPTIwDQpJcyB0aGlzIHN1ZmZpY2llbnQgZ3JvdW5kcyB0byBqdW5r IGl0PyBJZiBpdCBpcyBub3Qgd2lkZWx5IGltcGxlbWVudGVkID0NCnlldD0yMA0KYmVjYXVzZSBv ZiBpbmhlcmVudCBwcm9ibGVtcywgdGhlbiBmaW5lLCBidXQgaWYgaXQgaXMgc2ltcGx5IGR1ZSB0 byBpdHM9MjANCm5ld25lc3MobXkgdm90ZSkgd2UgcmlzayBkZWxheWluZyB0aGUgaW1wbGVtZW50 YXRpb24gb2YgZWl0aGVyIGJ5IG11ZGR5aW5nID0NCnRoZT0yMA0Kd2F0ZXIgd2l0aCB0aGUgaW50 cm9kdWN0aW9uIG9mIGEgc2Vjb25kLg0KDQo+ICBpdCB3b3VsZCBzZWVtIHRoYXQgYSBkcmFmdCB3 aGljaCBwcm9wb3NlcyBhbiBhbHRlcm5hdGl2ZQ0KPmNlcnQgcHVibGlzaGluZyBtZWNoYW5pc20g YXMgYW4gSW50ZXJuZXQgU3RhbmRhcmQgd291bGQgaGF2ZSBhIGhpZ2gNCj5idXJkZW4gb2YgcHJv b2YgdG8ganVzdGlmeSB0aGUgZHVwbGljYXRpb24uDQoNCklmIHRoaXMgZHJhZnQgd2FzIGNvbWlu ZyBvdXQgdGhyZWUgeWVhcnMgZnJvbSBub3csIHllcy4gQXMgaXQgaXMsIHdlID0NCmhhdmU9MjAN CnNvIGxpdHRsZSB1bmRlcnN0YW5kaW5nIG9mIFMvTUlNRSBjdXN0b21lciBuZWVkcywgSSBkb24n dCB0aGluayBoYXZpbmcgPQ0KYW49MjANCmFsdGVybmF0aXZlIG1lY2hhbmlzbSBpcyBoYXJtZnVs Lg0KDQo+ICAgVGhlIElFU0cgaXMgcmVsYXRpdmVseQ0KPnN0cmljdCBpbiBkaXNjb3VyYWdpbmcg dGhlIGRlZmluaXRpb24gb2Ygb3ZlcmxhcHBpbmcgbWVjaGFuaXNtcy4NCg0KV2Ugb25seSB3aXNo LiA6LSkgQSB0b3BpY2FsbHkgcmVsZXZhbnQgY291bnRlcmV4YW1wbGU6IFMvTUlNRSBhbmQgT3Bl blBHUC4NCg0KW08nTWFsbGV5LCBCYXJ0bGV5XT0yMA0KUGF1c2UgZm9yIGEgbW9tZW50Li4uIERv IHlvdSByZWFsbHk/KHdpc2ggdGhhdCBpcykNCg0KSWYgeW91IGRpZCwgd2h5IHdvdWxkIHlvdSBz dXBwb3J0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgYW4gb3ZlcmxhcHBpbmcgPQ0Kc3RhbmRhcmQuDQoN Ci0tUGF1bCBIb2ZmbWFuLCBEaXJlY3Rvcg0KLS1JbnRlcm5ldCBNYWlsIENvbnNvcnRpdW0NCg0K DQotLV9fX19LWkZPSU1QTUZPTURXRkxYV1dLWV9fX18NCkNvbnRlbnQtVHlwZTogdGV4dC94LXZj YXJkOyBjaGFyc2V0PXdpbmRvd3MtMTI1MjsgbmFtZT0iQm9iIEp1ZW5lbWFuLnZjZiINCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCkNvbnRlbnQtRGlzcG9zaXRp b246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJCb2IgSnVlbmVtYW4udmNmIjsNCgltb2RpZmljYXRp b24tZGF0ZT0iVHVlLCAyNiBPY3QgMTk5OSAxNzoxNTo0OCAtMDYwMCINCg0KQkVHSU46VkNBUkQN ClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpSb2JlcnQgUi4gSnVlbmVtYW4NClRFTDtX T1JLOjgwMS04NjEtNzM4Nw0KT1JHOk5vdmVsbCwgSW5jLjtOZXR3b3JrIFNlY3VyaXR5IERldmVs b3BtZW50DQpURUw7UFJFRjtGQVg6ODAxLTg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJK VUVORU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdp bmVlcg0KQURSO0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjtQUlYtRjMzMTsxMjIgRS4gMTcwMCBT b3V0aDtQcm92bztVdGFoOzg0NjA2O1VTPQ0KQQ0KTEFCRUw7SU5UTDtXT1JLO1BBUkNFTDtQT1NU QUw7RU5DT0RJTkc9M0RRVU9URUQtUFJJTlRBQkxFOlJvYmVydCBSLiA9DQpKdWVuZW1hbj0zRDBB PTNEDQpQUlYtRjMzMT0zRDBBPTNEDQoxMjIgRS4gMTcwMCBTb3V0aD0zRDBBPTNEDQpQcm92bywg VXRhaCAgODQ2MDY9M0QwQT0zRA0KVVNBDQpMQUJFTDtET007V09SSztQQVJDRUw7UE9TVEFMO0VO Q09ESU5HPTNEUVVPVEVELVBSSU5UQUJMRTpSb2JlcnQgUi4gPQ0KSnVlbmVtYW49M0QwQT0zRA0K UFJWLUYzMzE9M0QwQT0zRA0KMTIyIEUuIDE3MDAgU291dGg9M0QwQT0zRA0KUHJvdm8sIFV0YWgg IDg0NjA2DQpURUw7SE9NRToxLTgwMS03NjUtNDM3OA0KVEVMO0NFTEw6MS04MDEtMzYxLTE0MTAN ClRFTDtQUkVGOjEtODAxLTg2MS03Mzg3LCAxLTgwMC00NTMtMTI2Nw0KWC1HV1VTRVJJRDpCSlVF TkVNQU4NCkVORDpWQ0FSRA0KDQoNCi0tX19fX0taRk9JTVBNRk9NRFdGTFhXV0tZX19fXy0tDQqg ggofMIIFCDCCA/CgAwIBAgIaAhQAAAAUNP1e8mQuJK2QmnfLPCP/cgICA9owDQYJKoZIhvcNAQEF BQAwMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DMB4X DTk5MTAwOTE3MjAwMFoXDTA5MTAwOTE3MjAwMFowMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxveWVl IENBMRMwEQYDVQQKFApOT1ZFTExfSU5DMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xVzSeenZZTtL31xxaUyShV7D6ePzgxRoLsakDrf4EQfoxCC0bYfZJKOq9Q0TFbXSd72BcbowK1PR NXRFC5n9dr0Dh73i8ort/tkFhaFsRjEc3Xs4iZAeZZPJ6Et8oQggaBDofvFGfMW3l0YgRPU65+Hu ZqIx/PmqO5IR6XebcNjG3w4BIe54KdI4O2by1M/1FuJIvHpt+YNygt1BXVDv6vlf59jVKp6YFB9m 5KaIm5EjI8AH1Z+dAdT6SvzCTBr7WBolbU76ulSg0fsGvFgu7lREIj2xIh/CjinfXxQQrGb3ddn2 31HjSBZq5zZJOTm/6fxkSq6aRMVmxrnrpaQRMQIDAQABo4ICDjCCAgowCgYDVR0OBAMEAQEwDAYD VR0jBAUwA4ABATAPBgNVHRMBAQAEBTADAQH/MA4GA1UdDwEBAAQEAwIBBjCCAcsGC2CGSAGG+DcB CQQBAQEABIIBtzCCAbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0 cDovL2RldmVsb3Blci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNf djEwLmh0bTCCAUSgGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgw BgIBAQIBCgIBaaIGAgEYAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA AAAAMBgwEAIBAAIIf/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBS oVICAQICAgD/AgEAAw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEB AAIBFDAVMBACAQACCH//////////AQEAAgEUok4wTAIBAgICAP8CAQADDQCA//////////////8D CQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAIIf/////////8BAf8wDQYJKoZI hvcNAQEFBQADggEBAGohEpuwC0ipAiPOo2MnkT8zWs02OH9Bnqakz4ncDOeOoQ2SsZBXyo6KfZ4W QxINEsY+vZC+5paqMFZVOnYKBD4KsD4JT9IwTutBMs6o6K61W56bkjVFaGPujsspsq3Ta8dgxkwU 6rCP4rqyC67dVdm/IqEwFkqfZR6+S8QDsUIE3jTDCP2+QdLE5QJcATW59itW9dRH2HcUppEGX7EF QpnypfMtsahe19vluOWYHXr9PyUMQl5UVaBhDG7IbO1eQBAoPans5/XU8nwl9Z0vmKC5CX9JIb9j K3H6zdUhthBrrFdjVQ8QnVxbi4clscAMVS6COSzSDCxWuD/LwIpwsSUwggUPMIID96ADAgECAhoC FAAAABQ0/V7yZC4krZCad8s8I/9yAgIE6jANBgkqhkiG9w0BAQUFADAyMRswGQYDVQQLExJOb3Zl bGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkxMDA5MTgxODAwWhcNMDEx MDA5MTgxODAwWjBCMRIwEAYDVQQDEwlCSnVlbmVtYW4xDTALBgNVBAsTBE5TUkQxDDAKBgNVBAsT A1BSVjEPMA0GA1UEChMGTm92ZWxsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt3h7 hk+uvRlsxrjGEiL3s5j3RBRdJ23ZYar9CsHmxuVh4uE4i8l+7PJevtAkEQBfaxUIRHYeyNpbYvYY KzTo6OEmb8VND7LUHDfWnerrFzMxwWt+l499ZCVIYLihCqQmlGBplj3KunoS3LsU79J7qtULwBky Kowk+cv7aUsKNp16W/VFzhKWYPApi+jkyo+OHAJh8z5OnRJV8Re0o54ZDTmDb8ILPwH2vu4jl9C7 +r02CXms9XpJSjEqCX+ZmfxGXyY1JH+Yw0XSG+UaINvx1jBLAbz9r4Iga1dZ8FRRgZKX7NasKtAO 4d1HRm5vDZc4BTLNpZbarTjWxomSuVDKAwIDAQABo4ICBTCCAgEwDAYDVR0jBAUwA4ABATAiBgNV HREBAQAEGDAWgRRCSlVFTkVNQU5Abm92ZWxsLmNvbTCCAcsGC2CGSAGG+DcBCQQBAQEABIIBtzCC AbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVsb3Bl ci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCCAUSg GgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaIG AgEUAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIBAAII f/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBSoVICAQICAgD/AgEA Aw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEBAAIBFDAVMBACAQAC CH//////////AQEAAgEUok4wTAIBAgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAS MBACAQACCH//////////AQEAMBIwEAIBAAIIf/////////8BAQAwDQYJKoZIhvcNAQEFBQADggEB AIhCHYqMfOAXyZc/LLjiXUxMJLibE9QG7CwcFsxKcHwUuRURoJTsisJY/BavmxZoJwV//8G1uII7 rYABLsPH1xlGkPXdqsFJ9Ok2vAvAHga+15sax3tR7OGAUH6rVaXW2Q2rIHjoSYSkgDJiG7+42o8C PaGfd2kucPwK5ExhZvoaXsWbEh7U43ChQEPe+zPkMG54pZpwXz2IkJPsv7hnAHiaiUZ5s23625s5 abMqoMiRDQvsw+DubavRp+d6R6RtRJ41/2Td/ozNByiHP6w7kPskOHty0Xnp60W5gKA5Q+ZKxdrH xV6YWz/Oh1DHMrW51w4AW7SmHVbR/5AwzBwjEAUxggF3MIIBcwIBATBQMDIxGzAZBgNVBAsTEk5v dmVsbCBFbXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQwIaAhQAAAAUNP1e8mQuJK2QmnfL PCP/cgICBOowCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQB5+R9hWJGej/xJSwMGx7RbwKGW BrKT5VJZ+10AJNFYzU9OWmSYMtgsJTk8CETXclDR72RaMAMNFsAcSuLNJmqOOtL4kSVYXOl62EcC JlMQsPWZIbJeeaxcohryuyDvh+Y6pm2VOP4dBOm09lpVD7XoozedpgMzTcWsE0m1SdiajyrskQkO sykZPiluRh+s1vpTqflApMMRTXWwxMc3pKS08huNYPE2V48dZpPI4mjA+07bQjXDjr0wx4Hpsb/4 7SOFxQPLEGiH6Mf+OeAvQYEk2HWD+UTHsylPuzsU33/9sZrEiHyEnfCOKvkWCQy+r+D2kfPeeaLJ NaPkNDoCDGWk Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA04752 for ietf-smime-bks; Tue, 26 Oct 1999 13:15:23 -0700 (PDT) Received: from barbar.esat.kuleuven.ac.be (root@barbar.esat.kuleuven.ac.be [134.58.56.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04738 for ; Tue, 26 Oct 1999 13:15:20 -0700 (PDT) Received: from bronx (bronx.esat.kuleuven.ac.be [134.58.189.79]) by barbar (version 8.8.5) with ESMTP id WAA14448; Tue, 26 Oct 1999 22:18:24 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Date: Tue, 26 Oct 1999 22:18:24 +0200 (CEST) From: Eurocrypt 2000 X-Sender: ec2000@bronx To: ietf-smime@imc.org Subject: Eurocrypt 2000 submission deadline: November 3, 1999 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------------------------------------------------------------- E U R O C R Y P T 2 0 0 0 May 14-18, 2000 Bruges (Brugge), Belgium http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ ------------------------------------------------------------- This is a reminder that the submission deadline for Eurocrypt 2000 is November 3, 1999. Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ for more information. ------------------------------------------------------------- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00217 for ietf-smime-bks; Tue, 26 Oct 1999 09:19:17 -0700 (PDT) Received: from citicorp.com (mango1.citicorp.com [192.193.195.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00210; Tue, 26 Oct 1999 09:19:03 -0700 (PDT) From: bartley.o'malley@citicorp.com Received: from myrtle2.citicorp.com (imta.citicorp.com [192.193.196.189]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id MAA17169; Tue, 26 Oct 1999 12:18:38 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (omroute4.email.citicorp.com [163.39.141.205]) by myrtle2.citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21750; Tue, 26 Oct 1999 12:21:12 -0400 (EDT) Received: from mercury.lew.gb.citicorp.com (root@mercury.email.citicorp.com [169.166.15.228]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA07923; Tue, 26 Oct 1999 12:19:51 -0400 (EDT) Received: from localhost (root@localhost) by mercury.lew.gb.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id RAA17649; Tue, 26 Oct 1999 17:16:50 +0100 (BST) X-OpenMail-Hops: 1 Date: Tue, 26 Oct 1999 17:16:40 +0100 Message-Id: Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt MIME-Version: 1.0 TO: ietf-smime@imc.org, phoffman@imc.org Content-Type: multipart/mixed; boundary="openmail-part-0c282f9e-00000001" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --openmail-part-0c282f9e-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Monday, October 25, 1999 5:09 PM To: ietf-smime Cc: phoffman Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. [O'Malley, Bartley] Is this sufficient grounds to junk it? If it is not widely implemented yet because of inherent problems, then fine, but if it is simply due to its newness(my vote) we risk delaying the implementation of either by muddying the water with the introduction of a second. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. [O'Malley, Bartley] Pause for a moment... Do you really?(wish that is) If you did, why would you support the introduction of an overlapping standard. --Paul Hoffman, Director --Internet Mail Consortium --openmail-part-0c282f9e-00000001 Content-Type: application/ms-tnef; name="WINMAIL.DAT" Content-Disposition: attachment; filename="WINMAIL.DAT" Content-Transfer-Encoding: base64 eJ8+ItxFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABAD0AAABSRTogV29ya2luZyBHcm91cCBM YXN0IENhbGw6ZHJhZnQtaWV0Zi1zbWltZS1jZXJ0ZGlzdC0wNC50eHQAZRUBA5AGABAAAAAB AAAAQAA5AED+VWPNH78BHAQBA5AGABQAAAABAAAAHgBCEAEAAAABAAAAAAAAAHMAAQOQBgAo AAAAAQAAAAIBcQABAAAAFgAAAAG/H81jAEObNe+LhhHTsJoAAfrU+5YAADwLAQOQBgBQAAAA AQAAAB4AcAABAAAAPQAAAFJFOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDpkcmFmdC1pZXRm LXNtaW1lLWNlcnRkaXN0LTA0LnR4dAAAAAAyFgEDkAYAQAAAAAEAAAACATEAAQAAAC0AAAA0 LjIuMS4xOTk5MTAyNTA5MDQ1My4wMGJjYmFhMChhKW1haWwuaW1jLm9yZwAAAAA2DAEDkAYA DAAAAAEAAAALAAIAAQAAAA8AAQOQBgAMAAAAAQAAAAMALgAAAAAAMgABA5AGABgAAAABAAAA HgA9AAEAAAAFAAAAUkU6IAAAAABTAQEDkAYALAAAAAEAAAAeAIsDCCAGAAAAAADAAAAAAAAA RgAAAAA4hQAAAQAAAAEAAAAAAAAAoAIBA5AGACwAAAABAAAAHgCMAwggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAKACAQOQBgAsAAAAAQAAAB4AjQMIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAACgAgEDkAYAJAAAAAEAAAADAI4DCCAGAAAAAADAAAAA AAAARgAAAAAYhQAAAAAAAGYCAQOQBgAkAAAAAQAAAAMAjwMIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAYAIBA5AGACQAAAABAAAAAwCQAwggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AABgAgEDkAYAJAAAAAEAAAALAJEDCCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAGcCAQOQ BgAkAAAAAQAAAAMAkgMIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAUwIBA5AGADAAAAAB AAAAHgCTAwggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAAAACSAwEDkAYA JAAAAAEAAAADAJQDCCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAK4DAQOQBgAgAAAAAQAA AAIBCzABAAAAEAAAAO41m0OGi9MRsJoAAfrU+5bwCAEDkAYADAAAAAEAAAADAIAQ/////5AE AQkABAACAAAAAAAAAAEDkAYADAAAAAEAAAALACMAAAAAAC8AAQOQBgAMAAAAAQAAAAsAKQAA AAAANQABBJAGALADAAACAAAAEgAAAB4AATABAAAACwAAACdwaG9mZm1hbicAAAIB/w8BAAAA NwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHBob2ZmbWFuAFNNVFAAcGhvZmZtYW5AaW1j Lm9yZwAAAwAVDAEAAAADAAAwAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgAaDAEAAAATAAAA TydNYWxsZXksIEJhcnRsZXkAAAACARkMAQAAAD8AAAAAAAAAjVVM0Ow8Ec6B/wgACbEDegEA AAALAAAAAAAAADEdTydNYWxsZXkeMh1CYXJ0bGV5HjUdNjBFVUxPTgAAHgADMAEAAAARAAAA cGhvZmZtYW5AaW1jLm9yZwAAAAACAQswAQAAABYAAABTTVRQOlBIT0ZGTUFOQElNQy5PUkcA AAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAAJAAAAcGhvZmZtYW4AAAAAAgH3XwEAAAA3AAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcGhvZmZtYW4AU01UUABwaG9mZm1hbkBpbWMub3Jn AAALAA8OAAAEgAMA/g8GAAAAAwAAOQAAAAALAEA6AQASAAMAcToAAAAAEwAAAB4AATABAAAA DQAAACdpZXRmLXNtaW1lJwAAAAACAf8PAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAA AABpZXRmLXNtaW1lAFNNVFAAaWV0Zi1zbWltZUBpbWMub3JnAAADABUMAQAAAAMAADABAAAA HgACMAEAAAAFAAAAU01UUAAAAAAeABoMAQAAABMAAABPJ01hbGxleSwgQmFydGxleQAAAAIB GQwBAAAAPwAAAAAAAACNVUzQ7DwRzoH/CAAJsQN6AQAAAAsAAAAAAAAAMR1PJ01hbGxleR4y HUJhcnRsZXkeNR02MEVVTE9OAAAeAAMwAQAAABMAAABpZXRmLXNtaW1lQGltYy5vcmcAAAIB CzABAAAAGAAAAFNNVFA6SUVURi1TTUlNRUBJTUMuT1JHAAMA/18AAAAAAwD9XwEAAAAeAPZf AQAAAAsAAABpZXRmLXNtaW1lAAACAfdfAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAA AABpZXRmLXNtaW1lAFNNVFAAaWV0Zi1zbWltZUBpbWMub3JnAAACAfYPAQAAAAQAAAAAAAAB CwAPDgAABIADAP4PBgAAAAMAADkAAAAACwBAOgEAAAADAHE6AAAAAB60 --openmail-part-0c282f9e-00000001-- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27735 for ietf-smime-bks; Tue, 26 Oct 1999 07:38:47 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27730; Tue, 26 Oct 1999 07:38:46 -0700 (PDT) Received: from ibm (A200-35.PPP.FTWO.TX.VERIO.NET [206.50.209.35]) by mailhost.onramp.net (8.9.3/8.9.3) with SMTP id JAA29643; Tue, 26 Oct 1999 09:41:48 -0500 (CDT) From: "Rik Drummond" To: "Paul Hoffman / IMC" , Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt Date: Tue, 26 Oct 1999 09:40:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.2.1.19991025090453.00bcbaa0@mail.imc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Paul... Rik -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Paul Hoffman / IMC Sent: Monday, October 25, 1999 11:09 AM To: ietf-smime@imc.org Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11324 for ietf-smime-bks; Mon, 25 Oct 1999 09:06:02 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11320 for ; Mon, 25 Oct 1999 09:06:01 -0700 (PDT) Message-Id: <4.2.1.19991025090453.00bcbaa0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 09:09:17 -0700 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt In-Reply-To: <199910251351.JAA04603@ara.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:51 AM 10/25/99 -0400, David P. Kemp wrote: >Since LDAP directories have both user and CA certificate attributes, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, Disagree. We are far from understanding how certificates are and will be published. LDAP certificate retrieval is well-defined, but not yet widely implemented, particularly for S/MIME MUAs. > it would seem that a draft which proposes an alternative >cert publishing mechanism as an Internet Standard would have a high >burden of proof to justify the duplication. If this draft was coming out three years from now, yes. As it is, we have so little understanding of S/MIME customer needs, I don't think having an alternative mechanism is harmful. > The IESG is relatively >strict in discouraging the definition of overlapping mechanisms. We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA09065 for ietf-smime-bks; Mon, 25 Oct 1999 06:52:06 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09061 for ; Mon, 25 Oct 1999 06:52:05 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA17051; Mon, 25 Oct 1999 09:55:28 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA17047; Mon, 25 Oct 1999 09:55:28 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA22918; Mon, 25 Oct 1999 09:54:43 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA04603; Mon, 25 Oct 1999 09:51:19 -0400 (EDT) Message-Id: <199910251351.JAA04603@ara.missi.ncsc.mil> Date: Mon, 25 Oct 1999 09:51:18 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt To: ietf-smime@imc.org, housley@spyrus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4DrYVkrB/I/zpO9rzRN9hg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Certdist draft 4 is an improvement over draft 3, in that it allows CAs (not just End Entities) to sign the SMimeCertificatePublish object and it allows End Entity certificates to be published in the userCertificate attribute in lieu of the proposed userSmimeCertificate attribute. However, it is still not clear what certificate publishing problem certdist is trying to solve. Section 2 says: "LDAP currently has the userCertificate property [attribute? -- dpk] defined for just that purpose. ... While some directories, such as X.500 directories, provide for a directory entry to contain the CA certificate, this is not the case for all directories." Since LDAP directories have both user and CA certificate attributes, and LDAP is the Internet mechanism of choice for publishing and retrieving certificates, it would seem that a draft which proposes an alternative cert publishing mechanism as an Internet Standard would have a high burden of proof to justify the duplication. The IESG is relatively strict in discouraging the definition of overlapping mechanisms. The draft should cite at least one example of an Internet directory which: 1) is used to distribute certificates, 2) could be modified to include the proposed userSmimeCertificate attribute, and 3) could not be modified to contain the standard caCertificate attribute. If such a directory exists, and needs to be accommodated in an Internet Standard, I propose that the following be added to section 4.3, which subsumes the LDAP-specific wording currently in section 4.5: 4.3 CertificateSet If the SMimeCertificatePublish object is published in the LDAP userSmimeCertificate attribute, the SignedData->certificates field of the object MUST be absent. If the SMimeCertificatePublish object is distributed by other means, this draft imposes additional restrictions ... This would ensure that LDAP directories only have to store one copy of user and CA certificates in the standard user- and CA-certificate attributes, instead of duplicating user certificates in two attributes and maintaining duplicate copies of CA certificates for every user. In LDAP directories, userSmimeCertificate would thus contain only the signed attributes; the eContent and CertificateSet fields would be empty. Dave Kemp > Announcing S/MIME Working Group Last Call. > > Title : Certificate Distribution Specification > Author(s) : J. Schaad > Filename : draft-ietf-smime-certdist-04.txt > Pages : 20 > Date : 21-Oct-99 > > Current methods of publishing certificates in directory services are > restricted to just certificates. This document provides a method of > publishing certificates with secondary support information such as > the SMimeCapabilities attribute (containing bulk algorithm support) > in a way that is both authenticated and bound to a given > certificate. > > Working Group Last Call will close after the IETF meeting. It will close > on 14 November. > > S/MIME WG Chair, > Russ Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA05443 for ietf-smime-bks; Mon, 25 Oct 1999 03:58:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05439 for ; Mon, 25 Oct 1999 03:58:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03544; Mon, 25 Oct 1999 07:01:46 -0400 (EDT) Message-Id: <199910251101.HAA03544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-03.txt Date: Mon, 25 Oct 1999 07:01:46 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-03.txt Pages : 8 Date : 22-Oct-99 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022140310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022140310.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id CAA02212 for ietf-smime-bks; Mon, 25 Oct 1999 02:32:58 -0700 (PDT) Received: from cmcltd.com ([196.12.38.91]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02188 for ; Mon, 25 Oct 1999 02:31:26 -0700 (PDT) Received: from localhost (kris@localhost) by cmcltd.com (8.8.7/8.8.7) with ESMTP id PAA10601 for ; Mon, 25 Oct 1999 15:56:24 +0530 Date: Mon, 25 Oct 1999 15:56:24 +0530 (IST) From: V KRISHNA REDDY To: ietf-smime@imc.org Subject: S-MIME key length Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I want the information whether s-mime specification gives us the flexibilty to use 1024 bit key length.Actually what is the status of the specification regarding key length. --krishna Received: by mail.imc.org (8.9.3/8.9.3) id OAA10307 for ietf-smime-bks; Fri, 22 Oct 1999 14:28:50 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA10303 for ; Fri, 22 Oct 1999 14:28:49 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA26155 for ; Fri, 22 Oct 1999 14:23:24 -0700 (PDT) Message-Id: <4.2.0.58.19991022172442.00a20840@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 17:27:54 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Working Group Last Call:draft-ietf-smime-certdist-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Announcing S/MIME Working Group Last Call. Title : Certificate Distribution Specification Author(s) : J. Schaad Filename : draft-ietf-smime-certdist-04.txt Pages : 20 Date : 21-Oct-99 Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. Working Group Last Call will close after the IETF meeting. It will close on 14 November. S/MIME WG Chair, Russ Received: by mail.imc.org (8.9.3/8.9.3) id OAA09544 for ietf-smime-bks; Fri, 22 Oct 1999 14:23:59 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA09533; Fri, 22 Oct 1999 14:23:56 -0700 (PDT) Message-Id: <4.2.1.19991022142649.00be0680@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 22 Oct 1999 14:27:52 -0700 To: Russ Housley , ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Proposed Charter Update In-Reply-To: <4.2.0.58.19991022153652.00a31a90@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >December 1999: > Last call on CMS and ESS examples document. We've had a slow start on the examples draft (but are now moving ahead; -03 was turned in yesterday). I'd move this to February 2000 to be realistic. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id OAA06816 for ietf-smime-bks; Fri, 22 Oct 1999 14:01:49 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA06809 for ; Fri, 22 Oct 1999 14:01:47 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA25494 for ; Fri, 22 Oct 1999 13:56:18 -0700 (PDT) Message-Id: <4.2.0.58.19991022153652.00a31a90@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 15:37:45 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Proposed Charter Update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please review and comment. Russ = = = = = = = = = = = S/MIME Mail Security (smime) Chair: Russ Housley Security Area Director: Jeffrey Schiller Marcus Leech Mailing Lists: General Discussion: ietf-smime@imc.org To Subscribe: ietf-smime-request@imc.org Archive: http://www.imc.org/ietf-smime/ Description of Working Group: The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications. The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks. The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of "mandatory to implement" algorithms may be selected. To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document. Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined. In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. Compressing data before encrypting it or signing it has a number of advantages. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compressed will provide all of these advantages. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent. S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large organizations will be used as examples. S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate. The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap. Goals and Milestones: History: First draft of small subgroup attack avoidance. First draft of certificate distribution specification. First draft of domain security services document. First draft of CMS and ESS examples document. First draft of KEA and SKIPJACK algorithm specification. First draft of IDEA algorithm specification. First draft of CMS RecipientInfo extension. First draft of CAST algorithm specification. October 1999: First draft of security label usage specification. First draft of elliptic curve algorithm specification. First draft of CMS compressed data content type specification. Last call on certificate distribution specification. November 1999: First draft of mail list key distribution. Updated draft of domain security services document. Last call on CAST algorithm specification. Last call on small subgroup attack avoidance. Last call on KEA and SKIPJACK algorithm specification. Submit small subgroup attack avoidance as Informational RFC. Submit KEA and SKIPJACK algorithm specification as Informational RFC. December 1999: Last call on CMS and ESS examples document. Last call on IDEA algorithm specification. Last call on CMS RecipientInfo extension. January 2000: Last call on security label usage specification. Last call on mail list key distribution. Last call on CMS compressed data content type specification. Submit certificate distribution specification as a Proposed Standard. February 2000: Last call on elliptic curve algorithm specification. Submit CAST algorithm specification as Informational RFC. March 2000: Submit CMS and ESS examples document as Informational RFC. Submit IDEA algorithm specification as Informational RFC. Submit CMS RecipientInfo extension as a Proposed Standard. Submit mail list key distribution as a Proposed Standard. April 2000: Submit CMS compressed data content type specification as a Proposed Standard. May 2000: Submit elliptic curve algorithm specification as a Proposed Standard. Submit security label usage specification as Informational RFC. July 2000: Last call on domain security services document. September 2000: Submit domain security services as Experimental RFC. Received: by mail.imc.org (8.9.3/8.9.3) id JAA15261 for ietf-smime-bks; Fri, 22 Oct 1999 09:09:13 -0700 (PDT) Received: from cnuproxy. (cnuproxy.cnu.edu.cn [202.204.208.13]) by mail.imc.org (8.9.3/8.9.3) with SMTP id JAA15246; Fri, 22 Oct 1999 09:09:06 -0700 (PDT) From: searchers@freeola.com Received: from 202.204.208.13 by cnuproxy. (SMI-8.6/SMI-SVR4) id AAA06205; Sat, 23 Oct 1999 00:08:36 +0800 Message-Id: <199910221608.AAA06205@cnuproxy.> To: Friend@public.com Date: Fri, 22 Oct 99 14:31:36 EST Subject: Your Web Page Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Increase your Web Site visiblity ! Try out : *** Proven Web Page Optimisation Software *** >> Audited results 55% Number 1 90% top 5 << *** Macro Media Web Page Design Software **** >>> Make your Web Pages sparkle <<<< **** Accept checks from your Web Site ***** >>>> Improve your margins & Cashflow <<<< Go to : http://www.pcpages.com/bizzinews/ ++++ Sender & Remove Instructions ++++ Free Business Links Bevere Close Worcester Tel 121 643 2448 Email : searchers@freeola.com ++++++++++++++++++++++++++++++++++++ Received: by mail.imc.org (8.9.3/8.9.3) id DAA20333 for ietf-smime-bks; Fri, 22 Oct 1999 03:56:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA20326 for ; Fri, 22 Oct 1999 03:56:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06172; Fri, 22 Oct 1999 06:59:11 -0400 (EDT) Message-Id: <199910221059.GAA06172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-certdist-04.txt Date: Fri, 22 Oct 1999 06:59:11 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Certificate Distribution Specification Author(s) : J. Schaad Filename : draft-ietf-smime-certdist-04.txt Pages : 20 Date : 21-Oct-99 Current methods of publishing certificates in directory services are restricted to just certificates. This document provides a method of publishing certificates with secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-certdist-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-certdist-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991021143006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-certdist-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-certdist-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021143006.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by mail.imc.org (8.9.3/8.9.3) id DAA07280 for ietf-smime-bks; Wed, 20 Oct 1999 03:55:45 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA07276 for ; Wed, 20 Oct 1999 03:55:44 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24384; Wed, 20 Oct 1999 06:58:16 -0400 (EDT) Message-Id: <199910201058.GAA24384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-domsec-03.txt Date: Wed, 20 Oct 1999 06:58:16 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 : Domain Security Services using S/MIME Author(s) : T. Dean, W. Ottaway Filename : draft-ietf-smime-domsec-03.txt Pages : 8 Date : 19-Oct-99 This document describes how the S/MIME protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely - for example when two domains use incompatible messaging technologies such as X.400 and SMTP/MIME. This document is also applicable to organisations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-domsec-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-domsec-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019140149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-domsec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-domsec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019140149.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by mail.imc.org (8.9.3/8.9.3) id OAA27924 for ietf-smime-bks; Thu, 14 Oct 1999 14:09:42 -0700 (PDT) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA27917 for ; Thu, 14 Oct 1999 14:09:41 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA26723 for ; Thu, 14 Oct 1999 14:03:55 -0700 (PDT) Message-Id: <4.2.0.58.19991014164821.00a018d0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 14 Oct 1999 16:51:15 -0400 To: ietf-smime@imc.org From: Russ Housley Subject: Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you want to have a time slot on the agenda in DC, please drop me an note today. Russ Received: by mail.imc.org (8.9.3/8.9.3) id MAA09220 for ietf-smime-bks; Mon, 11 Oct 1999 12:47:12 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09215 for ; Mon, 11 Oct 1999 12:47:11 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HK0>; Mon, 11 Oct 1999 12:48:24 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Walter Williams'" , "'Russ Housley'" Cc: "'wpolk@nist.gov'" , "'ietf-smime@imc.org'" Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:48:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keyboard focus bug -- lets finish the message this time. I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if there are sufficent pointers in the certificate to allow it to be found. (i.e. an AIA extension with an ldap URI). I will update the draft to this and post before the end of the week. jim -----Original Message----- From: Jim Schaad (Exchange) Sent: Monday, October 11, 1999 12:46 PM To: 'Walter Williams'; Russ Housley Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if -----Original Message----- From: Walter Williams [mailto:walter.williams@gte.com] Sent: Sunday, September 12, 1999 7:30 PM To: Russ Housley; jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Russ, One thought here is backwards compatability of existing s/mime aware clients. Some may have been written to check for the cert in only one of the available attributes. You don't want to change the directory in a way which prevents an older client from seeing the certificate. (might though give vendors a thrill to have to say: so sorry, but due to a standard change we must force you to upgrade to support s/mime again) Certificates are also not very large (compaired with a .jpg picture of the directory entrant as a comparitive example) and so the data bloat does not waste much drive space. Of course, if all available clients look in both places, my statement is pretty much a waste of good bandwidth. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Russ Housley Sent: Sunday, September 12, 1999 12:35 PM To: jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Jim: I must agree with many of the points that Dave Kemp made. Is it worth putting multiple copies of the same certificate into the Directory? This can lean to inconsistincies. Maybe it would be better to follow the PKIX LDAP Schema and add an S/MIME-specific attribute too the directory entry. The binding you seek could be achieved by putting a reference to a specific certificate that is available in the userCertificate attribute inside the S/MIME-specific attribute. Thoughts? Russ Received: by mail.imc.org (8.9.3/8.9.3) id MAA09187 for ietf-smime-bks; Mon, 11 Oct 1999 12:44:47 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09183 for ; Mon, 11 Oct 1999 12:44:46 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HHB>; Mon, 11 Oct 1999 12:45:59 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Walter Williams'" , Russ Housley Cc: wpolk@nist.gov, ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:46:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I do know that current clients exist in the market who only look at one element (mine for one), however I don't believe that this should stand in the way of creating a "correct" standard. I agree that it makes sense to allow for the EE certificate to be optional if it exists in the userCertificates property. I think that the chain certificates can be optional if -----Original Message----- From: Walter Williams [mailto:walter.williams@gte.com] Sent: Sunday, September 12, 1999 7:30 PM To: Russ Housley; jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Russ, One thought here is backwards compatability of existing s/mime aware clients. Some may have been written to check for the cert in only one of the available attributes. You don't want to change the directory in a way which prevents an older client from seeing the certificate. (might though give vendors a thrill to have to say: so sorry, but due to a standard change we must force you to upgrade to support s/mime again) Certificates are also not very large (compaired with a .jpg picture of the directory entrant as a comparitive example) and so the data bloat does not waste much drive space. Of course, if all available clients look in both places, my statement is pretty much a waste of good bandwidth. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of Russ Housley Sent: Sunday, September 12, 1999 12:35 PM To: jimsch@EXCHANGE.MICROSOFT.com Cc: wpolk@nist.gov; ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Jim: I must agree with many of the points that Dave Kemp made. Is it worth putting multiple copies of the same certificate into the Directory? This can lean to inconsistincies. Maybe it would be better to follow the PKIX LDAP Schema and add an S/MIME-specific attribute too the directory entry. The binding you seek could be achieved by putting a reference to a specific certificate that is available in the userCertificate attribute inside the S/MIME-specific attribute. Thoughts? Russ Received: by mail.imc.org (8.9.3/8.9.3) id MAA09135 for ietf-smime-bks; Mon, 11 Oct 1999 12:42:08 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09131 for ; Mon, 11 Oct 1999 12:42:07 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCW4HDJ>; Mon, 11 Oct 1999 12:43:20 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Russ Housley'" Cc: ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST Date: Mon, 11 Oct 1999 12:43:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Use of this element has what I consider to be a fatal flaw -- specifically it is not protected in any way. There is nothing to prevent me from changing the value that you see retrieved from the directory in such a way to allow you to detect it. (consider changing the algorithms from 3DES to RC2/40 for example). After all, as a rule one does not bother looking up ones own data in a directory to see if it has been changed recently. jim -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Thursday, September 16, 1999 9:51 AM To: jimsch@EXCHANGE.MICROSOFT.com Cc: ietf-smime@imc.org Subject: RE: Cert Attributes in CERTDIST X.509-1997 defines the supported algorithm attribute. There seems to be a lot of overlap. Russ = = = = = = = = = = 12.2.2.8 Supported algorithms attribute A Directory attribute is defined to support the selection of an algorithm for use when communicating with a remote end entity using certificates as defined in this Directory Specification. The following ASN.1 defines this (multi-valued) attribute: supportedAlgorithms ATTRIBUTE ::= { WITH SYNTAX SupportedAlgorithm EQUALITY MATCHING RULE algorithmIdentifierMatch ID id-at-supportedAlgorithms } SupportedAlgorithm ::= SEQUENCE { algorithmIdentifier AlgorithmIdentifier, intendedUsage [0] KeyUsage OPTIONAL, intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL } Each value of the multi-valued attribute shall have a distinct algorithmIdentifier value. The value of the intendedUsage component provides an indication of the intended usage of the algorithm (see 12.2.2.3 for recognized uses). The value of the intendedCertificatePolicies component identifies the certificate policies and, optionally, certificate policy qualifiers with which the identified algorithm may be used. Received: by mail.imc.org (8.9.3/8.9.3) id GAA04580 for ietf-smime-bks; Mon, 4 Oct 1999 06:20:04 -0700 (PDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA04576 for ; Mon, 4 Oct 1999 06:20:03 -0700 (PDT) Received: from Dell (dyn-1-1-229.Cor.dialup.oleane.fr [62.161.8.229]) by s2.smtp.oleane.net with SMTP id PAA84332; Mon, 4 Oct 1999 15:21:14 +0200 (CEST) Message-ID: <006c01bf0e6b$5491e400$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: From Firewall to IPSec VPNs Date: Mon, 4 Oct 1999 15:21:11 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01BF0E7C.16E36C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0069_01BF0E7C.16E36C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference >From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm ------=_NextPart_000_0069_01BF0E7C.16E36C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Security services and protection mechanisms
IPv6 promises = regarding=20 IPSec
Certification infrastructure
Standardization update
Case = Studies:=20 ISPs, carriers, private networks
AH and ESP protocols = description
Possible=20 future extensions and modifications of the IKE = protocol
Complementarity=20 between IPSec and firewalls
Global Site-to-Site IPSec VPN's with = End-to-End=20 SLA's
Managing widespread IPSEC virtual private networks
Solving = IPSec=20 VPNs scalability
Results of some interoperability tests
IPSec=20 architectures and non-standardized aspects of IPSec
Adding IPSec VPN=20 functions in an existing router network
Impact of fragmentation on = the=20 performance of IPSec coding

IPSEC 99 Conference
From Firewall = to IPSec=20 VPNs

October 26, 27, 28, 29, 1999
Paris - France

More = infos: www.upperside.fr/baipsec.htm=
 
------=_NextPart_000_0069_01BF0E7C.16E36C80--